What “code smells” are there that are a symptom that an event listener model is required?

Question

What are the symptoms in a code base that indicate that an event-listener approach is required?

It seems to me that when there are classes that need to be called by multiple, not defined at design-time set of other classes, you need some sort of signaling framework, but I would like to hear what other situations are there that would be improved by changing to an event-based model.

Answer 1

The Event/Listener aproach tries to avoid tight coupling, so all code smells that indicate that, would point to the appoach.

Based on that, i would suggest the following symptoms:

• big constructors, as every object needs to know every other object, and cannot function without. Maybe disguised as many obj.set_dependecy(x) immediately following the constructor call.

• bidirectional dependencies, because, without events, in an imperative language, the flow of information is basically 'push' (calling someones method)

• 'hierarchy of knowledge' is hard to determine. This is the bidirectional dependencies, just another focus: if there's A, that listens to B, A knows of B, but B doesn't of A, so there's a 'hierachy': some objects don't know anything, some know other, etc. For example, when implementing MVC like this: http://en.wikipedia.org/wiki/Model_View_Controller, the model knows only itself, the view knows the model, and the controller knows view and model.

Answer 2

When you cannot or shouldn't know what should react to a set of messages/signals/events.

Often it's when you want "the world" to know about something hapening in a module (a class or a system of classes) but you don't want to bother about what is called.

The associated code smell, to be specific, is when you feel that you start to mix code from independant modules, one doing something that the other one should react to. Once you see that you have to call code from module B depending on the state/events of module A, you need event listeners.

Answer 3

Think about what you'd have to do if event-listeners (aka. the Observer Pattern) didn't exist.

If you have an object that has references to a list of other objects and calls a method on them at a given point in the process, you definitely should have had an event there.

If you have a flag on an object to say that something has been done and you are watching that flag from other objects, you definitely should have used an event-driven model.

However, do not confuse this with a callback. If you call a method on another object and pass it a method on the originating object to call back to at a given time, you should leave it that way, rather than using an event listener.

Answer 4

I would change your question and say: when an event based is not the right solution for an object oriented application? I think that most OO applications can benefit if they are designed as event producers and consumers.

In the end, a "method call" is in fact a message arriving at an object and the object is responsible for deciding if it's going do to something with the message and performing the operation. This is not very clear in strongly typed languages such as Java, but it becomes more obvious in dynamic languages such as Ruby.

Another interesting point of designing an application as event based is that usually the internal components have to be properly isolated and coherent, otherwise the code becomes a mess very, very quickly. As an example, I really like the concept of Hexagonal Architecture used by Alistair Cockburn, as usually this pattern creates a better encapsulation and forces (in my view) more cohesive components.

I think (but I'm probably wrong) that this is also related to the Domain Driven Design concept of Domain Events, in which the domain classes emit events that are captured by other objects, and these object emit yet other events (you see where this is going :D). What I like about this pattern is that says that interfaces should model Roles, not implementations.

Sorry if I don't make much sense, I've been experimenting with these patterns for the last few months with amazing results, but I'm still trying to understand the concepts and how far they reach.