Skip to main content
added 287 characters in body
Source Link

I have an interface Event and a class Agent.

I want to be able to write something like agent.handle(event).

However, the classes that implement the event interface will all have different fields and things that the agent.handle method would need to know about, and so I'm struggling between either:

  1. A switch on event type which then calls the relevant handler method in Agent and likely casts the event (which is basically like a chain of InstanceOfs which I know is a sign of bad design generally).

  2. Switching to something like event.applyTo(Agent), but it feels strange having an event 'happen to' an agent, as now the event (which should really just be a description of an event and not be coupled to agents specifically) would need to contain the handling logic.

Is there a design pattern for this kind of thing that I'm missing?

It seems like this kind of thing would be pretty common in event based systems where you want to decouple events from handlers when reading messages from a single input queue.

I've played about with how the Adapter pattern would look, and my understanding is that I'd have something like EventAdapter.handle(agent, event) but I basically don't like that solution.

I've came across this solution as well which I quite like, but I'm not sure if it's too verbose.

This question on SO also seems to be a similar problem, but the solutions are either stringly typed, and/or won't catch a missing handler for an event until runtime. And this one here on SE also suffers from the same problem.

I have an interface Event and a class Agent.

I want to be able to write something like agent.handle(event).

However, the classes that implement the event interface will all have different fields and things that the agent.handle method would need to know about, and so I'm struggling between either:

  1. A switch on event type which then calls the relevant handler method in Agent and likely casts the event (which is basically like a chain of InstanceOfs which I know is a sign of bad design generally).

  2. Switching to something like event.applyTo(Agent), but it feels strange having an event 'happen to' an agent, as now the event (which should really just be a description of an event and not be coupled to agents specifically) would need to contain the handling logic.

Is there a design pattern for this kind of thing that I'm missing?

It seems like this kind of thing would be pretty common in event based systems where you want to decouple events from handlers when reading messages from a single input queue.

I've played about with how the Adapter pattern would look, and my understanding is that I'd have something like EventAdapter.handle(agent, event) but I basically don't like that solution.

I've came across this solution as well which I quite like, but I'm not sure if it's too verbose.

I have an interface Event and a class Agent.

I want to be able to write something like agent.handle(event).

However, the classes that implement the event interface will all have different fields and things that the agent.handle method would need to know about, and so I'm struggling between either:

  1. A switch on event type which then calls the relevant handler method in Agent and likely casts the event (which is basically like a chain of InstanceOfs which I know is a sign of bad design generally).

  2. Switching to something like event.applyTo(Agent), but it feels strange having an event 'happen to' an agent, as now the event (which should really just be a description of an event and not be coupled to agents specifically) would need to contain the handling logic.

Is there a design pattern for this kind of thing that I'm missing?

It seems like this kind of thing would be pretty common in event based systems where you want to decouple events from handlers when reading messages from a single input queue.

I've played about with how the Adapter pattern would look, and my understanding is that I'd have something like EventAdapter.handle(agent, event) but I basically don't like that solution.

I've came across this solution as well which I quite like, but I'm not sure if it's too verbose.

This question on SO also seems to be a similar problem, but the solutions are either stringly typed, and/or won't catch a missing handler for an event until runtime. And this one here on SE also suffers from the same problem.

added 127 characters in body
Source Link

I have an interface Event and a class Agent.

I want to be able to write something like agent.handle(event).

However, the classes that implement the event interface will all have different fields and things that the agent.handle method would need to know about, and so I'm struggling between either:

  1. A switch on event type which then calls the relevant handler method in Agent and likely casts the event (which is basically like a chain of InstanceOfs which I know is a sign of bad design generally).

  2. Switching to something like event.applyTo(Agent), but it feels strange having an event 'happen to' an agent, insteadas now the event (which should really just be a description of an event and not be coupled to agents specifically) would need to contain the handling logic.

Is there a design pattern for this kind of thing that I'm missing?

It seems like this kind of thing would be pretty common in event based systems where you want to decouple events from handlers when reading messages from a single input queue.

I've played about with how the Adapter pattern would look, and my understanding is that I'd have something like EventAdapter.handle(agent, event) but I basically don't like that solution.

I've came across this solution as well which I quite like, but I'm not sure if it's too verbose.

I have an interface Event and a class Agent.

I want to be able to write something like agent.handle(event).

However, the classes that implement the event interface will all have different fields and things that the agent.handle method would need to know about, and so I'm struggling between either

  1. A switch on event type which then calls the relevant handler method in Agent and likely casts the event (which is basically like a chain of InstanceOfs which I know is a sign of bad design generally).

  2. Switching to something like event.applyTo(Agent), but it feels strange having an event 'happen to' an agent, instead of the handling logic.

Is there a design pattern for this kind of thing that I'm missing?

It seems like this kind of thing would be pretty common in event based systems where you want to decouple events from handlers when reading messages from a single input queue.

I've played about with how the Adapter pattern would look, and my understanding is that I'd have something like EventAdapter.handle(agent, event) but I basically don't like that solution.

I've came across this solution as well which I quite like, but I'm not sure if it's too verbose.

I have an interface Event and a class Agent.

I want to be able to write something like agent.handle(event).

However, the classes that implement the event interface will all have different fields and things that the agent.handle method would need to know about, and so I'm struggling between either:

  1. A switch on event type which then calls the relevant handler method in Agent and likely casts the event (which is basically like a chain of InstanceOfs which I know is a sign of bad design generally).

  2. Switching to something like event.applyTo(Agent), but it feels strange having an event 'happen to' an agent, as now the event (which should really just be a description of an event and not be coupled to agents specifically) would need to contain the handling logic.

Is there a design pattern for this kind of thing that I'm missing?

It seems like this kind of thing would be pretty common in event based systems where you want to decouple events from handlers when reading messages from a single input queue.

I've played about with how the Adapter pattern would look, and my understanding is that I'd have something like EventAdapter.handle(agent, event) but I basically don't like that solution.

I've came across this solution as well which I quite like, but I'm not sure if it's too verbose.

added 163 characters in body
Source Link

I have an interface Event and a class Agent.

I want to be able to write something like agent.handle(event).

However, the classes that implement the event interface will all have different fields and things that the agent.handle method would need to know about, and so I'm struggling between either

  1. A switch on event type which then calls the relevant handler method in Agent and likely casts the event (which is basically like a chain of InstanceOfs which I know is a sign of bad design generally).

  2. Switching to something like event.applyTo(Agent), but it feels strange having an event 'happen to' an agent, instead of the handling logic.

Is there a design pattern for this kind of thing that I'm missing?

It seems like this kind of thing would be pretty common in event based systems where you want to decouple events from handlers when reading messages from a single input queue.

I've played about with how the Adapter pattern would look, and my understanding is that I'd have something like EventAdapter.handle(agent, event) but I basically don't like that solution.

I've came across this solution as well which I quite like, but I'm not sure if it's too verbose.

I have an interface Event and a class Agent.

I want to be able to write something like agent.handle(event).

However, the classes that implement the event interface will all have different fields and things that the agent.handle method would need to know about, and so I'm struggling between either

  1. A switch on event type which then calls the relevant handler method in Agent and likely casts the event (which is basically like a chain of InstanceOfs which I know is a sign of bad design generally).

  2. Switching to something like event.applyTo(Agent), but it feels strange having an event 'happen to' an agent, instead of the handling logic.

Is there a design pattern for this kind of thing that I'm missing?

It seems like this kind of thing would be pretty common in event based systems where you want to decouple events from handlers when reading messages from a single input queue.

I've played about with how the Adapter pattern would look, and my understanding is that I'd have something like EventAdapter.handle(agent, event) but I basically don't like that solution.

I have an interface Event and a class Agent.

I want to be able to write something like agent.handle(event).

However, the classes that implement the event interface will all have different fields and things that the agent.handle method would need to know about, and so I'm struggling between either

  1. A switch on event type which then calls the relevant handler method in Agent and likely casts the event (which is basically like a chain of InstanceOfs which I know is a sign of bad design generally).

  2. Switching to something like event.applyTo(Agent), but it feels strange having an event 'happen to' an agent, instead of the handling logic.

Is there a design pattern for this kind of thing that I'm missing?

It seems like this kind of thing would be pretty common in event based systems where you want to decouple events from handlers when reading messages from a single input queue.

I've played about with how the Adapter pattern would look, and my understanding is that I'd have something like EventAdapter.handle(agent, event) but I basically don't like that solution.

I've came across this solution as well which I quite like, but I'm not sure if it's too verbose.

Source Link
Loading