Pattern: Mediator

Synopsis

Mediator Pattern uses one object to co-ordinate state changes between other objects. This results in a more cohesive implementation of the logic and decreased coupling between the other classes.

Context

·        The Mediator pattern addresses a problem that commonly occurs in dialog boxes.

Click To expand

·        If each object in the dialog takes responsibility for the dependencies it is associated with, the result is a highly coupled set of objects with low cohesion.

Click To expand

·        Clearly, reorganizing these objects in a way that minimizes the number of connections and gathers the dependency handling into one cohesive object is a good thing. So here comes the Mediator Pattern:

Click To expand

Forces

·        You have a set of related objects and most of the objects are involved in multiple dependency relationships.

·        Classes are difficult to reuse because their basic function is interlinked with dependency relationships.

This is the motivation for the particular solution. It summarizes the considerations that lead one to the general solution presented in the next section.

Solution

Here it is how classes and interfaces participate in Mediator pattern.

Click To expand

·        Colleague1, Colleague2, and so on: When they need to notify other objects about a state change, they call a method of the Mediator object. The Mediator object’s method takes care of the rest.

·        EventListener1, EventListener2, and so on:  Colleague objects call the appropriate method of the appropriate interface without knowing the class of the Mediator object that implements the method.

·        Mediator: Instances of classes in the Mediator role have logic to process state notifications from Colleague1, Colleague2, and so on, objects.

Consequences

+          Most of the complexity involved in managing dependencies is shifted from other objects to the Mediator object. This makes the other objects easier to implement and maintain.

+          Colleague classes are more reusable because their core functionality is not interlinked with dependency-handling code.

-         Because dependency-handling code is usually application specific, Mediator classes are not usually reusable.

Implementation

See dvd_mediator_example.zip.

Reference: (URL): http://www.fluffycat.com/java/JavaNotes-GoFMediator.html

Related Patterns

Adapter 

Interface  

Observer  

 

 

Created By: Devdatta Lele. (leleda@wpi.edu)

 

Reference: Patterns in Java, Volume 1: A Catalog of Reusable Design Patterns Illustrated with UML, Second Edition, by Mark Grand 

URL:   http://library.books24x7.com/book/id_5397/viewer.asp?bkid=5397&destid=785