0

Imaging a simple double-dispatch event handling scheme:

enter image description here

It's cool. Moreover it works. However I see several issues here:

  1. EventHandlerInterface must explicitly know all the events.
  2. As a result of (1) handlers may have large space overhead because of subscribing for unused events.

What I want this structure to be, looks more like this:

enter image description here

As you can see, I want separate event types produced by different modules and I want for each module to implement only necessary event handling interfaces. I am not sure how to tie this all together. Ideally I would like to have a list of EventServices ready to accept any event.

One thing, I can think of here, is to have an inherited EventService for each EventHandlerInterface type and downcast event handlers to the certain type inside notify method. However it is not type safe and looks like an ugly idea.

Second approach, I can see, is to make EventService a template and statically check template argument to be a child of EventHandlerInterface. That would be type safe and will almost do what I want. However this way I can not store all EventServices into one list/vector as I would like to. Therefore this approach is not preferable.

Actually it feels like I am looking the wrong way but how to find the right one I don't know.

Thanks!

Long Smith
  • 1,339
  • 3
  • 21
  • 40
  • You might be more interested in an observer pattern, or a "signals and slots" approach for event management. Visitors are great when you are usually interested in all or most of the types. – AndyG Jan 21 '19 at 23:18

1 Answers1

1

I am not sure the visitor pattern is the right approach for this problem. Sure it gives you a mechanism to achieve double dispatch but that's about it, and as you said it has drawbacks, e.g. the visitor (EventHandlerInterface) has to provide an overload for every different type of host (EventInterface). This creates a tight coupling and only makes sense if you add classes to the host hierarchy very infrequently.

Why not go for a solution according to the publish-subscribe pattern? It allows loose coupling and avoids the need of redundant interfaces. In brief, the publisher offers some events, to which subscribers can subscribe. When an event is triggerd, subscribers are notified and handle it. Subscribers only subscribe to events they find relevant. Different subscribers can provide different handling for the same type of event, which seems to be the purpose of double dispatch in your case.

In many languages (e.g. C#) there is special syntax for supporting this pattern easily. In C++ you need to use a library such as boost signals although there are others too. See also here for an example.

opetroch
  • 3,929
  • 2
  • 22
  • 24
  • Thanks! It really looks more suitable for my task. Also I am aware of Boost signals/slot but unfortunately I need the pattern for embedded system and using Boost can have a footprint on flash memory usage. If you know some lightweight analog I would appreciate if you share it. – Long Smith Jan 22 '19 at 21:10
  • I haven't evaluated different libraries, so can't say much on this. Usually my criterion is simplicity and ease of use. E.g. in a personal project I use sigslots (http://sigslot.sourceforge.net/), super easy to use, just one header. Have you checked this thread: https://stackoverflow.com/questions/359928/which-c-signals-slots-library-should-i-choose ? – opetroch Jan 23 '19 at 00:15