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
Motivation Mozilla ver 1.4.1

• GKGFX rendering library
• From an abandoned code base
• Lines are dependency relationships

4
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

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
  beginhttp//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
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.

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 dont 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
Participants

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

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