From Symfony2's EventDispatcher component documentation:
The Symfony2 EventDispatcher component implements the Mediator pattern in a simple and effective way to make all these things possible and to make your projects truly extensible.
I have been reading about Event Aggregator and Mediator patterns and their differences. To me it looks like Event Aggregator is a specific case of Mediator, which uses events to facilitate communication, and has no business logic whatsoever inside. Mediator on the other hand is more generic, and can allow some business logic to decide if certain communication should go through.
So I checked the source code of Symfony2's EventDispatcher or TraceableEventDispatcher, and found that the only logic that may alter communication is checking if event propagation has been stopped, as follows:
protected function doDispatch($listeners, $eventName, Event $event)
{
foreach ($listeners as $listener) {
call_user_func($listener, $event, $eventName, $this);
if ($event->isPropagationStopped()) {
break;
}
}
}
Is this why EventDispatcher in Symfony2 implements Mediator pattern but not Event Aggregator pattern? If the logic to check for isPropagationStopped
is moved out of EventDispatcher (say, to the event listeners), then this would implements Event Aggregator?
Event Aggregator is similar to Observer pattern, the Subject just notifies to Observer objects that there's a change, those need to update no matter what kind of event it is.
Symfony2's EventDispatcher implements Mediator pattern because it acts like a router, decides what event will be triggered by the listener which can subscribe to more than one event. As you can see, even removing isPropagationStopped
part, EventDispatcher still needs the event name to determine which event to fire.
Anthony Ferrara has a great blog post discussing about this matter
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With