In the lecture you became familiar with Structural Pattern (Adapter, Bridge, Composite, Facade, [soon: Proxy]), Behavioral Pattern (Command, Observer, Strategy), and the Architectural Pattern “Model View Controller”. Next week you will learn as well about the Creational Pattern (Abstract Factory, Builder, Singleton). Knowing design pattern is essential for being productive in Object Oriented Software Construction. In addition they are not only useful for the construction of software, but as well for reading and understanding it.

Prepare the software you are about to study:

• Create a Java project “JHotDraw52” in Eclipse.
• Open the properties of the project and set the JDK Compliance (see Java Compiler) to 1.4
• Download JHotDraw 5.2, e.g. from http://download.sourceforge.net/jhotdraw/JHotDraw5.2.zip
• Use “Import” > “Archive File” to import the whole content of the zip file into your project.
• Right click on the “sources” folder in your project and select “Build Path” > “Use as Source Folder”

Your task is to find three design pattern in the source code (there are many more!) and be ready to explain them. Write a short text describing where to find the design pattern in the code and how it works. For each design pattern you should at least describe

1. which type (class or interface) is playing which role in the design pattern (e.g. “CompositeFigure” is playing the role of a “Composite”) and
2. three to five sentences about the collaboration between the roles as found in this source code.
3. Typically there are one or two locations in the design pattern, where you can easily add another class (e.g. it is easy to add a “Leaf” to a “Composite”) Find this location and either argue why it is easy and useful to add another class or just do it.

Write it in your own words! Don't copy from the thousand resources you can find on the web about JHotDraw. Of course you can read them, but don't copy them. You even find explanations in the project itself e.g.in the pattlets folder.

Tips:

• Be smart. Don't read too much code, but search e.g. for typical words (Searching for “Composite” gives you “CompositeFigure”), or just scan over the class names, or ask Dr. Google.
• For e.g. the Composite Pattern we would like to know:
  1. Which class is the Composite (See above)? Which class plays the Component role? How many classes are playing the Leaf role? Which?
  2. How does the Composite implement most of its operations? Does the rest of the code distinguish between Composites and Leaves? If “yes”: How? If “no”: Why?
  3. Explain that it is easy to add a Leaf and why this is useful (or just add one).
• If you just explained an instance of Composite last week, you should select other design patterns this week.

Tips if you are looking for more information:

• You may use as well a later version of JHotDraw, but we think this older version has the best documentation for design pattern.
• Do you want to see a JHotDraw application running? Then you have to set the Java compiler compliance level back to 1.4. The classes in the project, which can be run as Java Applications, are: CH.ifa.draw.samples.javadraw.JavaDrawApp, …net.NetApp, …pert.PertApplication, …nothing.NothingApp
• Information about JHotDraw may be found here: http://www.javaworld.com/javaworld/jw-02-2001/jw-0216-jhotdraw.html or http://www.jhotdraw.org/.

Class Diagram for the Mediator Pattern

• The Mediator pattern is a behavioural pattern.
• Interaction between different colleague objects gets encapsulated in a mediator object.
• The Mediator defines all possible interactions between the colleagues.
• A ConcreteMediator then implements these interactions between the ConcreteColleagues.
• If a ConcreteCollegue wants to communicate with another ConcreteCollegue they will not communicate directly, but through the ConcreteMediator.
• So there is no coupling in between the ConcreteColleagues but only between the ConcreteColleagues and the ConcreteMediator.

Your task is now:

1. Draw an Abstractness-Stability-Diagram¹⁾ for the mediator pattern.
   • We claim that if someone tells us that for some classes the Mediator is the right choice, we know already their (relative) position in the Abstractness-Stability-Diagram. Why? Explain why there is only one “good” way to arrange the classes in the diagram.
   • What does this tell you about the situations where the Mediator pattern is appropriate?
2. Find an example where the usage of the mediator pattern is useful.
   • Draw a class diagram that shows which part of your example corresponds to the classes of the pattern shown above.
3. Assume one or more classes are in a library (in a lower layer) and one or more classes are in an application using the library (in a higher layer).
   • Which of the classes would you expect in the library and which in the application? Explain in one to three sentences.

Take a look at the cyclic dependency expressed in the following UML class diagram: Can you think of a way to break this cycle without loosing any functionality?

Create a class diagram and explain the idea in two or three sentences.