Applied Design Patterns with Java
Behavioral :: Mediator (273) {C ch 20}
Implementation
The following implementation issues are relevant to the
Mediator pattern:
- Omitting the abstract Mediator class. There's no need to define an abstract Mediator class when colleagues work with
only one Mediator.
The abstract coupling that the Mediator class provides lets colleagues work with different Mediator subclasses, and vice versa.
- Colleague-Mediator communication. Colleagues have to communicate with their Mediator when an event
of interest occurs. One approach is to implement the Mediator as an Observer using the Observer (293) pattern. Colleague classes act as Subjects, sending notifications
to the Mediator whenever they change state. The Mediator responds by propagating the effects of the change to other colleagues.
Another approach defines a specialized notification interface in Mediator that lets colleagues be more direct in their communication. When
communicating with the Mediator, a colleague passes itself as an argument, allowing the mediator
to identify the sender.
Related Patterns
Facade (185) differs from Mediator in that it abstracts a subsystem of objects to provide a more convenient
interface. Its protocol is unidirectional; that is, Facade
objects make requests of the subsystem classes
but not vice versa. In contrast, Mediator enables cooperative behavior that colleague objects don't or can't
provide, and the protocol is multidirectional.
Colleagues can communicate with the Mediator
using the Observer (293) pattern.
Catalog Behavioral Prev Next