Mediator Design Pattern Jim Fawcett CSE776 – Design Patterns Summer 2006

Intent Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently

Motivation – Mozilla ver 1.4.1 GKGFX rendering library From an abandoned code base Lines are dependency relationships

Mutual Dependencies - Mozilla 1.4.1 Object Oriented Design encourages distribution of behavior among objects. Such distribution can result in an object structure with many connections between objects. In the worst case, every object ends up knowing about every other. www.castle-cadenza.demon.co.uk/mediat.htm

Quote from Mozilla Developer “Even though some of us used to work on Mozilla, we have to admit that the Mozilla code is a gigantic, bloated mess, not to mention slow, and with an internal API so flamboyantly baroque that frankly we can't even comprehend where to begin” http://news.com.com/2100-1023-980492.html

Problem Object-oriented design distributes behavior among different objects. This kind of partitioning is good since it encourages reuse. But… Sometimes the interactions between these objects becomes so intense, that every object in the system ends up knowing about every other object. Since the behavior may be distributed among different objects, it may sometimes become very difficult to change the system behavior without defining a lot of subclasses. Lots of interconnections make it less likely that an object can work without the support of others. Sometimes, complex protocols need to be managed and centralized points of access are desirable.

Air Traffic Control Tower Mediator Control tower at a controlled airport : Pilot communicating with the Traffic control. Some constraints on take off and landing are enforced by the tower Tower does not control the whole flight. It exists only to enforce constraints in terminal area. Air Traffic Controller

IDE Frame Window Mediator A framewindow is a mediator for its child windows: Provides the sites and color and font properties used by each. Provides the menu control that supports complex operations in child windows.

Forces Complex systems, of necessity, must be decomposed into many interacting components. Dense sets of dependencies makes change and reuse very difficult.

Solution Model a class whose object controls and coordinates the interactions of a group of other objects. which encapsulates collective behavior of the group of objects. Thus the Mediator object… Benefits promotes loose coupling by keeping objects from referring to each other explicitly. Allows the designer to vary their interaction independently. Objects don’t need to know about each other, they just need to know their Mediator. Mediators are generally used where complex protocols must be managed, and when centralized access points are desirable.

Static Structure

Participants Mediator Concrete Mediator Colleague ConcreteColleagues Defines an interface for communicating with colleague objects. Concrete Mediator Implements cooperation by coordinating colleagues. Colleague Provides a protocol for mediator/colleague interactions. ConcreteColleagues Knows how to contact mediator Does all communication through mediator.

Dynamic Structure

Collaborators ConcreteMediator Colleague Implements cooperation by coordinating colleague objects. Colleague Send and receive requests from a mediator object.

CONSEQUENCES Advantages – Limits subclassing – localizes behavior that would otherwise be distributed among several objects. Decouples colleagues – As the number of connections is limited by redirecting to a common object. Promotes high level of reusability – It proliferates the interconnections to help eventually reduce it. Due to loose coupling, both mediator and colleague classes can be reused independent of each other. Changing the system behavior means subclassing the Mediator.

CONSEQUENCES Disadvantages Might not be a good idea for a relatively small group of objects. Centralized control – Mediator encapsulates protocols and is more complex than individual colleagues, thus it might become a monolith itself, and hard to maintain. God class – Since it defines how all the colleagues interact, it knows too much about everything. As a counterpoint, it is entirely reasonable, in some cases, to have the mediator simply route messages, without implementing any other control. Thus control is distributed across all the colleagues. If each colleague is simply controlling its own activities, this makes a lot of sense.

IMPLEMENTATION Some of the implementation issues are: May omit the abstract Mediator class – this can be done when colleagues work with only one mediator. Implementing the Mediator-Colleague communication Message passing offers some interesting possibilities. The Mediator can be implemented as an Observer with the colleagues acting as subjects.

USES This pattern is used in: Air traffic control systems. 911 Emergency dispatching Matrix software research Gosh, Krishna, Appurdai, Fawcett GUI dialog managers COM run-time IIS Webserver

RELATED PATTERNS Relations with other patterns: Observer Façade If there are no constraints on the flow of information, this pattern resembles the Observer pattern. Façade If the mediator objects make requests of the colleague objects, but not vice-versa, this pattern will collapse into the Facade pattern. Relation to Adapter If the Mediator object were allowed to change the data it handles, this pattern would become the Adapter pattern.

Mediator-Based Code Analyzer