Chapter 10 Mediator

1. Chapter 10Mediator Summary prepared by Kirk Scott

2. AthenaFrom Wikipedia, the free encyclopedia • :"Athene", "Athina", and "Pallas Athena" all redirect here. For other uses, see Athena (disambiguation), Athene (disambiguation), Athina (disambiguation) and Pallas Athena (disambiguation)

3. In Greek religion and mythology, Athena or Athene (pron.: /əˈθiːnə/ or /əˈθiːniː/; Attic: Ἀθηνᾶ, Athēnā or Ἀθηναία, Athēnaia; Epic: Ἀθηναίη, Athēnaiē; Ionic: Ἀθήνη, Athēnē; Doric: Ἀθάνα, Athānā), also referred to as Pallas Athena/Athene (pron.: /ˈpæləs/; Παλλὰς Ἀθηνᾶ; Παλλὰς Ἀθήνη), is the goddess of wisdom, courage, inspiration, civilization, law and justice, just warfare, mathematics, strength, strategy, the arts, crafts, and skill. Minerva is the Roman goddessidentified with Athena.[4]

4. Athena is also a shrewd companion of heroes and is the goddess of heroic endeavour. She is the virgin patroness of Athens. The Athenians founded the Parthenon on the Acropolis of her namesake city, Athens (Athena Parthenos), in her honour.[4]

7. Athena in the art of Gandhara.

8. Design Patterns in JavaChapter 10Mediator Summary prepared by Kirk Scott

9. Introduction • A mediator is something that stands between one base class and another • In object terms, the mediator object stands between one or more instances of one or more base classes • Instances of the base classes interact with the mediator class rather than interacting with each other directly

10. The implementation of mediators can differ depending on what the relationships between instances of the base classes are • This means that the mediator pattern could be represented by a variety of UML diagrams

11. The background for mediators can be expressed in terms of responsibility • The general rule is that objects are responsible for themselves • In other words, classes should contain some well-defined, limited, and coherent data set, along with the methods needed to work with the data • Classes, in general, should not be heavily reliant on objects of other classes to implement needed functionality

12. On the other hand, recall the Builder pattern • It illustrated offloading construction responsibility/functionality into another class • Also recall the Proxy pattern • In it, the client dealt with the proxy (stand-in) rather than dealing directly with the base class

13. The Mediator pattern can be viewed as offloading/concentrating responsibility/functionality into a separate class • The mediator becomes responsible for the relationship between classes or the relationships between instances of those classes

14. Although conceptual in nature, the relationships are real aspects of the design • They can be as meaningful as the bases classes themselves • They canhave a life of their own • It turns out to make good design sense to have a separate class that is devoted to storing and maintaining the relationships

15. Scenario • Consider this scenario: • In a group of objects, each one “is aware of” or has a reference to every other member of the group • First of all, note that this can be complex

16. Also note that the set of relationships itself becomes an abstraction that might be implemented as a separate class • Introducing a new class factors the relationship functionality out of the base classes • The new class concentrates responsibility for the relationships among objects and reduces their responsibility for themselves

17. The individual objects become dependent on the class that maintains the relationships • In the code, the individual objects relate only to the class in the middle, not with each other • This new class in the middle is a mediator class • The base objects are no longer tightly coupled with each other, but they are tightly coupled with the mediator

18. Book Definition of the Pattern • Book definition: • The intent of the Mediator pattern is to define an object that encapsulates how a set of objects interact; this promotes loose coupling, keeping the objects from referring to one another explicitly, and lets you vary their interactions independently.

19. Comment mode on: • The pattern makes the base classes more loosely coupled with each other. • In a sense, it does this by coupling them to a common class in the middle. • They are coupled to the class in the middle by virtue of the fact that the class in the middle concentrates the responsibility for maintaining the relationships

20. Modeling Relationships • Keep in mind that code typically models some reality • In that reality, individual objects may be linked with each other • In the problem domain, the relationships may be as important as the objects, and exist as a truly separate concept

21. How you represent the relationships in code is a design choice • Correctly implementing the relationships in a separate class abstracts out the responsibility for maintaining relationships

22. Concrete Examples from the Book • The book pursues two examples to illustrate the use of the Mediator design pattern • 1. The pattern can become apparent/be used when developing GUI’s with multiple parts in increasingly complex relationships • 2. The pattern can also become apparent when modeling the real world where objects have relationships with each other and the code needs to reflect those relationships

23. The book will claim that the first example is the more common one • Before the dust has settled it should become apparent that the second example, even if less common, makes the logic of the pattern clearer

24. A Classic Example: GUI Mediators • The book’s first example applies the mediator pattern to a program with a graphical user interface • The book shows a GUI, shows some code, and shows a refactoring using the pattern • At the end of the book’s example, it basically comes down to this: • “Voila—and now you see how these things don’t interact directly with each other anymore—they interact through this other class in the design.”

25. In order to reduce the “voila” factor, it is helpful to give a preview of how it will fit together: • The example is based on tubs and machines

26. There will be base classes for tub and machine objects • There will also be a base class which keeps track of these objects in the data model • In this case, the class which takes care of the objects will be known as a “mock database” (stay tuned) • You can recognize that this as equivalent to the model in an MVC design

27. There will be a class that is responsible for the GUI components • This is the client • It graphically represents the objects in the application • It also has buttons, etc., so actions can be taken • You can recognize that this as equivalent to the view in an MVC design

28. There will be a mediator • This will implement listening • This is the functionality for what happens when an action is taken in the GUI • You can recognize that this as equivalent to the controller in an MVC design

29. In other words, analytically speaking, in an MVC design, the controller serves as a mediator between the model and the view • On the other hand, this example illustrates mediation without including the observer part of MVC • Why observing is extraneous will be pointed out later

30. Overall in this example a relationship between the data model and the graphical user interface representation of the state of the application has to be maintained • The mediator implements listening functionality • It stands between the GUI/client/view and the data model • It is responsible for maintaining the relationship

31. The Scenario • The graphical user interface for the example is shown on the overhead following the next one • A factory has machines in it, and the machines at any given time have a set of tubs of materials that belong to them • The interaction of interest is the moving of tubs from one machine to another

32. It is important to understand that at this point the book is interested in mediation between the graphical user interface and the data model in the application • It is apparent that there is another basic relationship in the application: • Which tubs are located at which machines • Applying mediation to that relationship will be covered in the next example

34. This is the sequence of events: • In the interface, pick a source machine from the first column • The tubs belonging to it appear in the second column • Destination machines appear in the third column • Pick a tub in the second column and a destination machine in the third column

35. Once three things are highlighted in the interface, you can press the “Do it!” button • This moves the tub from the source machine to the destination machine • Both the GUI representation and the underlying data model in the software should be updated

36. Extending the Development Scenario • The authors paint out the scenario further in this way • An interface like this can be developed using a wizard • However, the wizard produces cookie-cutter code that doesn’t necessarily fit a nice design pattern

37. Using a wizard might produce a class named MoveATub that is basically a monolithic application • The UML for this class is given on the next overhead

39. Refactoring the Design • The book observes that the methods in the MoveATub class are a mixture of component building, event handling, and “mock database” operations • The desire is to refactor this design so that it is better • In other words, the desire is to break it into parts where the responsibilities are clearly divided • In the long run this will make the code easier to maintain and modify

40. GUI Construction Methods in the Monolithic Class • There are methods in MoveATub that construct GUI components • For example, there is a method assignButton(), which is the method which constructs the “Do it!” button • Its code is given on the next overhead for reference • Notice that it is implemented with lazy initialization

41. private JButtonassignButton() • { • if(assignButton == null) • { • assignButton = new JButton(“Do it!”); • assignButton.setEnabled(false); • assignButton.addActionListener(this); • } • return assignButton; • }

42. Domain Object Construction in the Monolithic Class • There are also methods in MoveATub that construct domain objects like lists of machines and tubs, and so on • In other words, the elements of the problem domain are mixed with GUI elements

43. Listener Implementation in the Monolithic Class • MoveATub also implements the ActionListener and ListSelectionListener interfaces • In it you find methods that are related to actions, like valueChanged() and updateTubList() • The authors give the code for the valueChanged() method for reference • It is shown on the following overhead

44. public void valueChanged(ListSelectionEvent e) • { • // … • assignButton().setEnabled( • !tubList().isSelectionEmpty() • && !machineList().isSelectionEmpty()); • }

45. The book observes that at the very least you might consider moving the event handling methods into a different class • That would be a step towards applying the mediator pattern

46. Ways of Implementing Listening • How listening is implemented opens out into a somewhat broader topic • Think back to how listening was implemented in CSCE 202 • The orange book’s plan was this: • Implement listening in a separate listener class, but make it an inner class so that it had direct access to the instance variables of the outer class

47. What we’ve just seen in the monolithic MoveATub class is that the class itself can implement the listening interface • Among the points this book is making is that the monolithic class has too many different kinds of things in it • Classes should be coherent, single-purpose, and self-contained

48. Where to put listening and how to make sure listeners have access to the things they need are important topics in Java GUI programming • Essentially, these topics were covered in the MVC units • Having a model in one or more classes and separating listening and observing into one or more classes each is the most general solution

49. Redesigning the Application Using the Pattern • Challenge 10.1 • Complete the diagram in Figure 10.3 to show a refactoring of MoveATub, introducing a separate mock database class and a mediator class to receive the events of the MoveATub GUI.

50. Comment mode on: • As usual, doing this on your own verges on the impossible • What, for example, does the book mean by a mock database? • As usual, the only practical approach is to just look at the book’s solution and try and figure out what it means