Simple event dispatcher
Design


Is there a need for IEventDispatcher? Defining it as an abstract base class doesn't provide much utility if there's only ever going to be one derived class.
Is there any requirement for EventDispatcher::eventListeners to be of type std::multimap&lt;EventType, EventHandler&gt;? It doesn't seem like the ordering of elements has much relevance, so a std::unordered_multimap&lt;EventType, EventHandler&gt; might provide better performance. But: The current code doesn't even use any std::multimap specific functionality, so the easiest solution might actually be a std::unordered_map&lt;EventType, std::vector&lt;EventHandler&gt;&gt;.
There is no way to remove a specific EventHandler, only all EventHandlers registered for an EventType.
There's no way to pass arguments to an event handler. This might be necessary for some use cases, e.g. to indicate what changed.


  There's no easy way to provide both general event dispatching (handling multiple different EventTypes) and event-specific parameter passing (different parameter types for different events). Some solutions:
  
  
  Redefining the scope of EventDispatcher: Instead of handling multiple events in each EventDispatcher instance each instance is only responsible for handling one specific EventType. The parameter types can then be taken as template parameters.
  Make EventType a base class and inherit from it when parameters need to be passed (so more like EventArgs in C#). Requires EventType instances to be passed as references or pointers, and EventHandlers need to downcast internally to the concrete derived class. Many possible ways to get this wrong, and the compiler might not be able to help much.
  



Implementation issues


EventDispatcher::dispatch iterates over all entries in EventDispatcher::eventListeners. Why not use std::multimap::equal_range to then only iterate over all entries that match?


  This would be \$\mathcal{O}(k + \log n)\$ on average instead of \$\mathcal{O}(n)\$ (where \$n\$ denotes the number of all elements in the container, and \$k\$ denotes all elements for the relevant key), or \$\mathcal{O}(k)\$ on average for std::unordered_multimap.
  
  The proposed replacement std::unordered_map&lt;EventType, std::vector&lt;EventHandler&gt;&gt; would also have complexity \$\mathcal{O}(k)\$ (\$\mathcal{O}(1)\$ to find the vector, \$\mathcal{O}(k)\$ to iterate it) - even in the worst case.

Rule of Five violation: A custom destructor is declared for EventDispatcher, but no custom copy constructor, copy assignment operator, move constructor and move assignment operators are declared. This prevents the compiler from providing default implementations for those (or soon will, it currently is deprecated for compilers to do so in case of copy constructor and copy assignment operator).


  It would be easiest to just use the default compiler-provided destructor.

Inconsistent naming: IEventDispatcher.h has file extension .h, whereas EventDispatcher.hpp has file extension .hpp.
In EventDispatcher, all member functions inherited and overridden from IEventDispatcher lack the override keyword.
EventDispatcher::dispatch could be const.