chapter 10 mediator

Download Chapter 10 Mediator

Post on 22-Feb-2016

17 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

Chapter 10 Mediator. Summary prepared by Kirk Scott. Athena From Wikipedia, the free encyclopedia. - PowerPoint PPT Presentation

TRANSCRIPT

Slide 1

Chapter 10MediatorSummary prepared by Kirk Scott1AthenaFrom 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)2In Greek religion and mythology, Athena or Athene (pron.: /in/ or /ini/; Attic: , Athn or , Athnaia; Epic: , Athnai; Ionic: , Athn; Doric: , Athn), also referred to as Pallas Athena/Athene (pron.: /pls/; ; ), 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 goddess identified with Athena.[4]

3Athena 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]

45

6

Athena in the art of Gandhara.7

Design Patterns in JavaChapter 10MediatorSummary prepared by Kirk Scott8IntroductionA mediator is something that stands between one base class and anotherIn object terms, the mediator object stands between one or more instances of one or more base classesInstances of the base classes interact with the mediator class rather than interacting with each other directly9The implementation of mediators can differ depending on what the relationships between instances of the base classes areThis means that the mediator pattern could be represented by a variety of UML diagrams

10The background for mediators can be expressed in terms of responsibilityThe general rule is that objects are responsible for themselvesIn other words, classes should contain some well-defined, limited, and coherent data set, along with the methods needed to work with the dataClasses, in general, should not be heavily reliant on objects of other classes to implement needed functionality11On the other hand, recall the Builder patternIt illustrated offloading construction responsibility/functionality into another classAlso recall the Proxy patternIn it, the client dealt with the proxy (stand-in) rather than dealing directly with the base class12The Mediator pattern can be viewed as offloading/concentrating responsibility/functionality into a separate classThe mediator becomes responsible for the relationship between classes or the relationships between instances of those classes

13Although conceptual in nature, the relationships are real aspects of the designThey can be as meaningful as the bases classes themselvesThey can have a life of their ownIt turns out to make good design sense to have a separate class that is devoted to storing and maintaining the relationships

14ScenarioConsider this scenario: In a group of objects, each one is aware of or has a reference to every other member of the groupFirst of all, note that this can be complex

15Also note that the set of relationships itself becomes an abstraction that might be implemented as a separate classIntroducing a new class factors the relationship functionality out of the base classesThe new class concentrates responsibility for the relationships among objects and reduces their responsibility for themselves

16The individual objects become dependent on the class that maintains the relationshipsIn the code, the individual objects relate only to the class in the middle, not with each otherThis new class in the middle is a mediator classThe base objects are no longer tightly coupled with each other, but they are tightly coupled with the mediator

17Book Definition of the PatternBook 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.18Comment 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

19Modeling RelationshipsKeep in mind that code typically models some realityIn that reality, individual objects may be linked with each otherIn the problem domain, the relationships may be as important as the objects, and exist as a truly separate concept

20How you represent the relationships in code is a design choiceCorrectly implementing the relationships in a separate class abstracts out the responsibility for maintaining relationships

21Concrete Examples from the BookThe book pursues two examples to illustrate the use of the Mediator design pattern1. The pattern can become apparent/be used when developing GUIs with multiple parts in increasingly complex relationships2. 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 relationships22The book will claim that the first example is the more common oneBefore the dust has settled it should become apparent that the second example, even if less common, makes the logic of the pattern clearer23A Classic Example: GUI MediatorsThe books first example applies the mediator pattern to a program with a graphical user interfaceThe book shows a GUI, shows some code, and shows a refactoring using the patternAt the end of the books example, it basically comes down to this:Voilaand now you see how these things dont interact directly with each other anymorethey interact through this other class in the design.

24In 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

25There will be base classes for tub and machine objectsThere will also be a base class which keeps track of these objects in the data modelIn 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

26There will be a class that is responsible for the GUI componentsThis is the clientIt graphically represents the objects in the applicationIt also has buttons, etc., so actions can be takenYou can recognize that this as equivalent to the view in an MVC design

27There will be a mediatorThis will implement listeningThis is the functionality for what happens when an action is taken in the GUIYou can recognize that this as equivalent to the controller in an MVC design28In other words, analytically speaking, in an MVC design, the controller serves as a mediator between the model and the viewOn the other hand, this example illustrates mediation without including the observer part of MVCWhy observing is extraneous will be pointed out later29Overall in this example a relationship between the data model and the graphical user interface representation of the state of the application has to be maintainedThe mediator implements listening functionalityIt stands between the GUI/client/view and the data modelIt is responsible for maintaining the relationship

30The ScenarioThe graphical user interface for the example is shown on the overhead following the next oneA factory has machines in it, and the machines at any given time have a set of tubs of materials that belong to themThe interaction of interest is the moving of tubs from one machine to another31It 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 applicationIt is apparent that there is another basic relationship in the application: Which tubs are located at which machinesApplying mediation to that relationship will be covered in the next example

3233

This is the sequence of events:In the interface, pick a source machine from the first columnThe tubs belonging to it appear in the second columnDestination machines appear in the third columnPick a tub in the second column and a destination machine in the third column34Once three things are highlighted in the interface, you can press the Do it! buttonThis moves the tub from the source machine to the destination machineBoth the GUI representation and the underlying data model in the software should be updated

35Extending the Development ScenarioThe authors paint out the scenario further in this wayAn interface like this can be developed using a wizardHowever, the wizard produces cookie-cutter code that doesnt necessarily fit a nice design pattern

36Using a wizard might produce a class named MoveATub that is basically a monolithic applicationThe UML for this class is given on the next overhead

3738

Refactoring the DesignThe book observes that the methods in the MoveATub class are a mixture of component building, event handling, and mock database operationsThe desire is to refactor this design so that it is betterIn other words, the desire is to break it into parts where the responsibilities are clearly dividedIn the long run this will make the code easier to maintain and modify

39GUI Construction Methods in the Monolithic ClassThere are methods in MoveATub that construct GUI componentsFor example, there is a method assignButton(), which is the method which constructs the Do it! buttonIts code is given on the next overhead for referenceNotice that it is implemented with lazy initialization40private JButton assignButton(){ if(assignButton == null) { assignButton = new JButton(Do it!); assignButton.setEnabled(false); assignButton.addActionListener(this); } return assignButton;}41Domain Object Construction in the Monolithic ClassThere are also methods in M