Mediator

Law of Demeter “… the methods of a class should not depend in any way on the structure of any class, except the immediate (top-level) structure of their own class. Further, each method should send messages to objects belonging to a very limited set of classes only.” OOAD, page 116

Why Mediator? Common problem: Multiple objects of same or different classes must communicate/interact. Multiple dependencies complicate objects, lead to “spaghetti code.” Solution: Define an object that encapsulates how a set of objects interact and interconnect. Make that object the hub of communications, responsible for controlling and coordinating the interactions of clients – the colleague objects.

Analogies/Metaphors Air traffic control Stock market eBay No analogy fits perfectly, but think of an airplane approaching an airport as an object. Its state includes its location, heading and speed. It would need to communicate its state to other airplane objects and to know the state of all other planes in the same airspace – a task that would distract pilots from other aspects of flying the plane – except we have created a Mediator. Planes reports to a single authority – the object we call Air Traffic Control – and that mediator has responsibility for ensuring that two planes don’t try to occupy the same space.

Advantages/Uses Partition system into smaller objects. Simplifies classes/objects by placing inter-object communications in mediator. Promotes loose coupling. Clarify complex relationships. Limit subclasses. Improve object reusability. Simplify object protocols. Facilitates refinement by containing changes in mediator or single colleagues rather than requiring updates in all classes. We want loose coupling, of course, because strong coupling complicates a system. The more an element (module) is interrelated with other modules the harder it is to understand, change or correct. Complexity can be reduced by designing systems with the weakest possible coupling between modules. Limit subclasses – behaviors that might require subclasses may be assigned to Mediator. Protocols – ways in which object can act and react – limited to few core operations.

Dangers Mediator can become monolithic, violating proscription against “God” or manager classes and making it hard to maintain.

Sample Code Interface Command{ void execute(); } Class Mediator{ BtnView btnView; BtnSearch btnSearch; BtnBook btnBook; LblDisplay show; void registerView(BtnView v) { btnView = v; ) void registerSearch(BtnSearch s) { btnSearch = s; void registerBook (BtnBook b) { btnBook = b; void registerDisplay(LblDisplay d) { show = d; void book() { btnBook.setEnable(false); btnView.setEnabled(true) btnSearch.setEnabled(true); show.setText(“booking…”); If you have a complex GUI, whenever a button has been clicked, the related actions should be disabled or enabled. You may design a Mediator class to include all related classes:

continued void search() { btnSearch.setEnabled(false btnView.setEnabled(true); btnBook.setEnabled(true); show.setText("searching..."); } class BtnView extends JButton implements Command { Mediator med; BtnView(ActionListener al, Mediator m) { super("View"); addActionListener(al); med = m; med.registerView(this); public void execute() { med.view(); class BtnSearch extends JButton implements Command { BtnSearch(ActionListener al, Mediator m) { super("Search"); med.registerSearch(this); med.search(); class BtnBook extends JButton implements Command { BtnBook (ActionListener al, Mediator m) { super("Book"); med.registerBook(this); From the above design, you can see that the relationships among the classes, which also known as colleagues or participating classes, are multidirectional. Mediator class contains all the information about these classes and knows what these classes are going to do. The participating classes have to register themselves to the Mediator class.The MediatorDemo class will show the cooperation among the classes.

continued super("Just start..."); med = m; med.registerDisplay(this); setFont(new Font("Arial",Font.BOLD,24)); } class MediatorDemo extends JFrame implements ActionListener { Mediator med = new Mediator(); MediatorDemo() { JPanel p = new JPanel(); p.add(new BtnView(this,med)); p.add(new BtnBook(this,med)); p.add(new BtnSearch(this, med)); getContentPane().add(new LblDisplay(med), "North"); getContentPane().add(p, "South"); setSize(400,200); setVisible(true); public void actionPerformed(ActionEvent ae) { Command comd = (Command)ae.getSource(); comd.execute(); public static void main(String[] args) { new MediatorDemo(); java MediatorDemo

UML

UML

Related Patterns Façade – provides a unified interface to a set of interfaces to make a subsystem easier to use, but Façade does not add functionality and is not known by the subsystem classes. Observer – defines a one-to-many dependency between objects so that when one object changes state all dependents are notified and updated automatically. Observer distributes communication by introducing “observer” and “subject” classes; mediator encapsulates communication between other objects.

Sources http://www.javacamp.org/designPattern/mediator.html http://www.fluffycat.com//javasource/javapatterns/Dv dLowercaseTitle.txt http://www.vincehuston.org/dp/mediator.html http://www.patterndepot.com/put/8/mediator.pdf Design Pattern, GoF OOAD, Booch et al