Mediator Vs Observer Object-Oriented Design Patterns
In the original book that coined the terms Observer and Mediator, Design Patterns, Elements of Reusable Object-Oriented Software, it says that the Mediator pattern can be implemented by using the observer pattern. However it can also be implemented by having Colleagues (which are roughly equivalent to the Subjects of the Observer pattern) have a reference to either a Mediator class or a Mediator interface.
There are many cases when you would want to use the observer pattern, they key is that an object should not know what other objects are observing it's state.
Mediator is a little more specific, it avoids having classes communicate directly but instead through a mediator. This helps the Single Responsibility principle by allowing communication to be offloaded to a class that just handles communication.
A classic Mediator example is in a GUI, where the naive approach might lead to code on a button click event saying "if the Foo panel is disabled and Bar panel has a label saying "Please enter date" then don't call the server, otherwise go ahead", where with the Mediator pattern it could say "I'm just a button and have no earthly business knowing about the Foo panel and the label on the Bar panel, so I'll just ask my mediator if calling the server is O.K. right now."
Or, if Mediator is implemented using the Observer pattern the button would say "Hey, observers (which would include the mediator), my state changed (someone clicked me). Do something about it if you care". In my example that probably makes less sense then directly referencing the mediator, but in many cases using the Observer pattern to implement Mediator would make sense, and the difference between Observer and Mediator would be more one of intent than a difference in the code itself.
Observer
1. Without
Client1: Hey Subject, when do you change?
Client2: When did you change Subject? I have not noticed!
Client3: I know that Subject has changed.
2. With
- Clients are silent.
- Some time later ...
- Subject: Dear clients, I have changed!
Mediator
1. Without
- Client1: Hey Taxi1, take me some where.
- Client2: Hey Taxi1, take me some where.
- Client1: Hey Taxi2, take me some where.
- Client2: Hey Taxi2, take me some where.
2. With
- Client1: Hey TaxiCenter, please take me a Taxi.
- Client2: Hey TaxiCenter, please take me a Taxi.
These patterns are used in different situations:
The mediator pattern is used when you have two sub-systems with some dependency and one of them is due for a change, and since you might not want to change the system that depends on the other, you may want to introduce a mediator which will decouple the dependency between them. That way, when one of the sub-systems changes, all you have to do is to update the mediator.
The observer pattern is used when a class wants to allow other classes to register themselves and receive notifications upon events, e. g. ButtonListener etc.
Both of these patterns allow for lesser coupling, but are quite different.
The Observer pattern: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
The Mediator pattern: Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
Source: dofactory
Example:
The observer pattern: Class A, can have zero or more observers of type O registered with it. When something in A is changed it notifies all of the observers.
The mediator pattern: You have some number of instances of class X (or maybe even several different types:X, Y & Z), and they wish to communicate with each other (but you don't want each to have explicit references to each other), so you create a mediator class M. Each instance of X has a reference to a shared instance of M, through which it can communicate with the other instances of X (or X, Y and Z).