Mediator
Mediator
Before After
Applicability
• A set of objects communicate in a well-
defined but complex manner
• Reusing an object is difficult because it
refers to and communicates with many
other objects
• A behavior that's distributed between
several classes should be customizable
without a lot of subclassing
Structure
• Mediator
o defines an interface for communicating with Colleague objects
• ConcreteMediator
o knows and maintains its colleagues
o implements cooperative behavior by coordinating Colleagues
• Colleague classes
o each Colleague class knows its Mediator object
o each colleague communicates with its mediator whenever it would
have otherwise communicated with another colleague
Object Structure
Consequences
1. Loose coupling between objects in program.
2. Change the behavior of the program by simply changing
or sub classing the Mediator.
3. Add new Colleagues to a system without having to
change any other part of the program.
4. Mediator solves the problem of each Command object
needing to know too much about the objects and
methods in the rest of a user interface.
5. The Mediator can become monolithic in complexity,
making it hard to change and maintain.
6. Difficult to reuse as Each Mediator is a custom-written
class that has methods for each Colleague to call and
knows what methods each Colleague has available.
Implementations
1. The Mediator pattern we have described above acts as
a kind of Observer pattern, observing changes in the
Colleague elements.
2. Omitting abstract mediator class.
3. Another approach is to have a single interface to
Mediator, and pass that method various constants or
objects which tell the Mediator which operations to
perform.
4. In the same fashion, we could have a single Colleague
interface that each Colleague would implement, and
each Colleague would then decide what operation it was
to carry out.
5. Mediators are not limited to use in visual interface
programs, we can use whenever complex
intercommunication between a number of objects.