When to Use the Mediator Pattern and Applicability
The fundamental idea of the Mediator is that you insert one more objects in between all the interacting components. The components do not talk to each other directly. Instead, when they want to signal a change or get some data, they ask the Mediator for it.
The intent of the Mediator pattern is to define an object that encapsulates how a set of objects interact.
The Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Though partitioning a system into many objects generally enhances reusability, proliferating interconnections tend to reduce it again.
Lots of interconnections make it less likely that an object can work without the support of others.
The system acts as though it were monolithic. Moreover, it can be difficult to change the system's behavior in any significant way, since behavior is distributed among many objects.
As a result, you may be forced to define many subclasses to customize the system's behavior.
Object-oriented design encourages the distribution of behavioramong objects. Such distribution can result in an object structurewith many connections between objects; in the worst case, every objectends up knowing about every other.
The Mediator pattern is a good idea when:
Changes in the state of one object affects many other objects.
The sheer number of interconnections between objects makes the system unwieldy and hard to change.
You want to be able to change the parts of a system independently from each other.
Figure 3 - Object Interaction: Mediator as a Communication Hub.
In contrast to the diagram on the preceding page (see Figure2 on the previous page), the Mediator pattern can be used to design a controlled, coordinated communication model for a group of objects, eliminating the need for objects to refer to each other directly . The Mediator pattern suggests abstracting all object interaction details into a separate class, referred to as a Mediator, with knowledge about the interacting group of objects.
Every object in the group is still responsible for offering the service it is designed for, but objects do not interact with each other directly for this purpose.
The interaction between any two different objects is routed through the Mediator class and all objects send their messages to the mediator.
The mediator then sends messages to the appropriate objects as per the requirements of the application. The resulting design has the following major advantages:
With all the object interaction behavior moved into a separate (mediator) object, it becomes easier to alter the behavior of object interrelationships, by replacing the mediator with one of its subclasses with extended or altered functionality.
Moving interobject dependencies out of individual objects results in enhanced object reusability.
Because objects do not need to refer to each other directly, objects can be unit tested more easily.
The resulting low degree of coupling allows individual classes to be modified without affecting other classes.