Observer instead of Mediator pattern #9912
Conversation
Actually EventDespacher component implements Observer pattern (GoF) but not a Mediator. I think we should change this description so as not to confuse users in the future.
|
The EventDispatcher is a clever mix of both, but the Mediator is more suited if we had to choose one. |
|
Because the actual observers are registered listeners. |
|
re #2817 To me it always seemed like it implements none of the two. |
|
EventDispatcher implements the Mediator pattern. See also the detailed PR description in #2817 In Observer, a subject class keeps track of it's own observers and notifies them. It would look like: class UpdateBlogPostHandler implements SubjectInterface
{
use SubjectTrait;
public function handle(UpdateBlogPost $command)
{
// ... update blog post
$this->notify(new BlogPostUpdated($command->getId(), $command->getNewBody());
}
}Whereas the Mediator pattern uses a "god class" that keeps track of all subjects and all observers (like Symfony's class UpdateBlogPostHandler
{
private $mediator;
public function __construct(EventDispatcherInterface $mediator)
{
$this->mediator = $mediator;
}
public function handle(UpdateBlogPost $command)
{
// ... update blog post
$this->mediator->notify(new BlogPostUpdated($command->getId(), $command->getNewBody());
}
} |
|
Change in docs can mention |
|
The replies so far are: Mediator, Both and None ... so this is getting more and more complicated to decide 😱 |
|
The Mediator is the simplest way to define what the dispatcher is. The docs should be about its usage, not about going deep in its internal architecture conception explanation, IMHO we'd better keep the docs as is. |
|
To me, the Symfony |
No, they're not, but for the case of the Event Dispatcher, it kinda implements both patterns, that's all 😉 |
|
Most of you mentioned that the component implements the two patterns. Could we reword this as follows then? Original: Proposal: |
|
Sounds good to me. |
|
Thanks Denis. We merged in 2.8 branch and later we'll merge in the upper branches automatically. |
This PR was submitted for the 2.7 branch but it was merged into the 2.8 branch instead (closes #9912). Discussion ---------- Observer instead of Mediator pattern Actually Event Dispatcher component implements Observer pattern (GoF) but not a Mediator. I think we should change this description so as not to confuse users in the future. <!-- If your pull request fixes a BUG, use the oldest maintained branch that contains the bug (see https://symfony.com/roadmap for the list of maintained branches). If your pull request documents a NEW FEATURE, use the same Symfony branch where the feature was introduced (and `master` for features of unreleased versions). --> Commits ------- 21ed3d2 Mention that the component implements both patterns 44e1e45 Update event_dispatcher.rst f1b41ca Update event_dispatcher.rst 31a2315 Observer instead of Mediator pattern
|
To me the However, in the Consider a weather station (example taken from the Head First Design Patterns book), whenever the temperature sensor captures a new temperature, the weather station updates its internal state and notifies its many observers (for instance a LED display, alarm buzzer, etc.) to be aware of the new temperature. The Symfony dispatcher doesn't maintain any state. When an event is dispatched, the series of listeners are invoked and receive the event. At the end of the dispatch method call, no state has been changed internally in the dispatcher. This is why we can't really consider the dispatcher a The My 2 cents. |
Actually Event Dispatcher component implements Observer pattern (GoF) but not a Mediator.
I think we should change this description so as not to confuse users in the future.