Events and Commands are two communication tools that I use really often. I have planned more exhaustive articles on the topic, but now I want to write a short post about one rule I apply when I use them. Sometimes it occurs to me the question: should the listener class know the dispatcher  class or the dispatcher class know the listener class?

Generally I answer in this way:

If I use event listeners, I inject the dispatcher inside the class which defines the method callback, ie:

In this way I do not need to expose the private members of the listener.

On the other way around, if I use the command pattern to achieve object communication (and I do it at lot), I usually invert the logic.

This because the Command Pattern add an extra layer of abstraction that does not let the dispatch and the listener know each other directly.

Using this rule I often end up with tidy code, so I hope it can help you as well.


  1. Avatar

    Short yet interesting article! This is a topic that is often overlooked, even being so important to game programming.

    I’ve been using the command pattern for a while in games, and it helped me keeping the code more organized, centralizing actions’ codes in a single place. I also implemented (sort of) a command pattern on my dependency injection container (, and I’d like your input on the way commands are dispatched (not necessarily about the container, but more in a general sense).

    The pattern states that we should have an invoker class, just like in your example. However, to make things simple, it always seemed to me that dispatching commands directly, i.e. without having to have a “man in the middle” (the invoker) was a good approach (which not necessarily would hurt single responsibility). So, e.g. if some class need to dispatch an event, it receives a reference of the dispatcher and simply dispatches any commands it needs. Even commands can dispatch other commands, given they can also receive a reference to the dispatcher. What do you think about it?

    Another concern is about the approach above and coupling. When dispatching commands, I always prefered to dispatch them by type (like in your example, but mostly using generics) rather than using some enum or string constants to define events’ names. However, this always makes me think about coupling, given the object where the command is dispatched must know the command it’ll dispatch in a strongly typed fashion (but in the case of an invoker will be mostly the same). This is good in a way (I can have the compiler’s help on checking commands), but bad in another (the coupling). Since my first command implementation with that idea in mind, this drives me nuts from time to time! (However I have never faced any problem with it even on large codebases.) What are your thoughts about it?


    1. sebas77

      Hello, I now use generics as well. I also don’t remember what that CommandDispatcher was, I am going to remove it from the example. I don’t use middle classes to dispatch, but I do use a CommandFactory. Knowing the type of a command is not a problem for coupling, it doesn’t make much sense to abstract commands. Some IoC containers use Command Maps, mapping events to commands, but I don’t like this solution to be part of a framework.

      1. Avatar

        Thanks for the reply!

        Now I accept in peace of mind that my approach is ok!

Leave a Reply