Why does Symfony EventDispatcher use arbitrary names for events instead of class-based propagation?

Question

I'm looking to implement Observer Pattern into my app (not php, that's why not using Symfony's component).

I found it strange though that the component is not using classes to propagate or listen to events since that would allow listening on whole tree of events using inheritance.

I can't see the single advantage of using name-based listeners, would you help me with my pondering?

Peccadillo

Answer 1

Symfony2, in my opinion, favors cohesion over coupling and that's why they use this pattern (Mediator pattern).

From Symfony docs:

Objected Oriented code has gone a long way to ensuring code extensibility. By creating classes that have well defined responsibilities, your code becomes more flexible and a developer can extend them with subclasses to modify their behaviors. But if he wants to share his changes with other developers who have also made their own subclasses, code inheritance is no longer the answer.

Consider the real-world example where you want to provide a plugin system for your project. A plugin should be able to add methods, or do something before or after a method is executed, without interfering with other plugins. This is not an easy problem to solve with single inheritance, and multiple inheritance (were it possible with PHP) has its own drawbacks.

The Symfony2 Event Dispatcher component implements the Mediator pattern in a simple and effective way to make all these things possible and to make your projects truly extensible.

Fourcycle