CSC/ECE 517 Fall 2012/ch2b 2w43 iv
Mediator Pattern
Introduction
Mediator pattern comes under the category of behavioral pattern<ref name="wikibehav">http://en.wikipedia.org/wiki/Behavioral_pattern
</ref>. It specifies an object that includes the encapsulation about the interaction among various objects.
It prevents objects to interact with each other explicitly and thus it facilitates loose coupling<ref name="wikiloosecoupling">http://en.wikipedia.org/wiki/Loose_coupling
</ref>. In other words it handles complex communication among related objects. All the objects communicate with the mediator when they want to interact with each other. Thus it improves maintainability.
All the classes which interact with the mediator are called colleagues. These colleagues know who their mediator is and the mediator also knows which colleagues can interact with it. The colleagues send messages to the mediator object. The mediator sends message to other classes. Thus the object which initiated this communication does not need to have knowledge about other objects. All they need to know is about their mediator who is responsible to carry out this communication.
Following classes/objects take part in this process:
Mediator: Provides interface for communication among colleagues.
Concrete Mediator: It coordinates the colleagues and implements cooperative behavior. It also holds information about the colleagues.
Colleague Classes: Colleague classes know about their mediator.
A real life example of mediator pattern can be of an airport control tower. It is the job of this tower to control all the planes. It decides which plane will take-off and land at what time rather than plane to plane communication.
Case1: Without the use of Mediator Pattern
In this example, there are four departments of a hospital, namely :Pathology, Radiology, Surgery and Physiology. When one department needs some data from another department, they need to explicitly contact the other department for that data. Since these departments directly interact with each other, the communication between these parties is very complex and results in high coupling.
For Example: When the Pathology department needs X-Ray report from the Radiology department(which is handled by the 'generateXRay()' method of the Radiology department) it calls it's 'getXRay()' method.
Similarly, there are other methods which are often required by other departments.
Case2: With the use of Mediator Pattern
To reduce coupling in the above example we add a Hospital Management Mediator which sits in between all the departments and all the communication among them is handled by the mediator. The control logic of the entire system is included in the mediator.
Whenever a new department is added or some functionality of an existing department needs to be changed, only the mediator control logic needs to be modified.
This facilitates loose coupling as the departments do not need to communicate with each other explicitly. They also do not need to know about internal details of other departments.
For example: the 'getXRay()' method of the Pathology department is now inside the Hospital Management Mediator and is called only of the patient is of type 'Pathology Patient'.
Advantages of Mediator Pattern
- It facilitates re-usability of objects. It is possible due to the fact that objects are decoupled from the system.
- Overall maintenance of the system gets simplified because the control logic is encapsulated in the mediator.
- It is the only smart delegating object
- Reduces subclassing
Disadvantages of Mediator Pattern
- It increases complexity. It tends to become more complex if more classes are added.
Facade Pattern
A Facade design pattern provides a unified interface to a larger body of code. It is a structural pattern<ref name="wikistructural">http://en.wikipedia.org/wiki/Structural_pattern
</ref>. This makes the use of subsystem easy. This pattern wraps the complicated subsystem with a simple interface. A facade pattern shields users from the complex inner details of the subsystem. Example of facade pattern could be of a web service where users can get access to the small services without knowing anything about their internal structures. They just need an interface which facade pattern provides.
Example
For the same example as discussed above let us see how a facade pattern looks.
In this case a facade pattern provides an interface to the patients through which they can interact with the departments. The internal details of the departments are hidden from the patient. So whenever he needs to get any service from any of the department he only communicates with the interface. The patient may not be provided with all the functionality and he is exposed to only certain functionality.
In this example, the patient has access to the facade interface and can only call the 'getFullReport()' method to obtain the checkup reports.
The 'getFullReport()' method in turn calls various methods of various departments. Thus the patient is unaware of the implementation of these methods.
Comparison of mediator pattern with facade pattern
- Mediator pattern is a behavioral pattern whereas facade pattern is a structural pattern.
- Mediator pattern adds extra functionality whereas facade pattern doesn’t add any extra functionality. It only provides an interface to an existing subsystem.
- The components of a subsystem do not have any knowledge about the facade whereas the colleagues have the knowledge of the mediator.
So if we see the above examples we can clearly understand that mediator pattern avoids coupling within a sub-system whereas facade pattern avoids coupling between sub-system and between sub-system and an external entity.
Observer Pattern
In an observer pattern an object maintains a list of all its dependents. Thus if any state changes occurs the object notifies all the dependents. The state of an object is an important concern. Whenever state change occurs the objects are updated automatically. All the common components are maintained in an abstraction called ‘subject’ whereas all the variable components are maintained in an abstraction called ‘object’. It is also known as publish-subscribe pattern. One example of observer pattern can be an event management process. Whenever an event takes place it should be notified to all other objects so that their state gets updated.
Example
In this case there is one subject and three dependent objects. The Hospital Management Subject implements the Subject interface. The three dependents/observers are Radiology, Physiology, and Surgery and they implement the Observer interface.
The Hospital Management Subject includes a method 'getBloodCount()' which sets the value of blood count variable.
Whenever the value of this variable for a particular patient changes the observers get notified of the change because they are registered with the subject.
The 'notify()' method calls the 'update()' method on the observer which sets the value in the observer objects.
Comparison of mediator pattern with observer pattern
- The mediator pattern differs from observer pattern in terms of usage. In order to avoid explicit communication between two or more objects mediator is used.
Whereas observer pattern is used in situations where an object changes its state all its dependents are notified and updated automatically to reflect this change.
References
<references />