Mediator Design Pattern

1. Mediator Design Pattern Jim Fawcett CSE776 – Design Patterns Summer 2006

2. 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

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

4. 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 Mutual Dependencies - Mozilla 1.4.1

5. 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

6. 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.

7. Air Traffic Control Tower Mediator • 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

8. 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. IDE Frame Window Mediator

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

10. 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.

11. Static Structure

12. Mediator 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. Participants

13. Dynamic Structure

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

15. 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.

16. 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.

17. 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.

18. 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

19. RELATED PATTERNS • Relations with other patterns: • Observer • 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.

20. Mediator-Based Code Analyzer