Release date: Thursday, 20.06.13 - Due date: Monday, 24.06.13, 23:59

In the lecture we explained that we do not consider a good decision to let the class Stack be a subtype of List (or AbstractList). Repeat the argument and demonstrate the problem with a short program.

Write a program that demonstrates the advantages of the Composite design pattern. The program should create a tree of objects consisting of both composite and leaf nodes (demonstrating that the composite has correctly implemented a subset of the child management functions, such as addChild(), getChild(), and getParent()). Make sure that your tree consists of at least three levels, e.g. a root node with multiple children, where at least one of those nodes is a composite node with children. The program should then call an operation on the root of the tree. All composite objects should delegate the operation to their children while all leaf nodes should perform the action. Optionally the composite nodes can do something in response to the operation but they should then delegate the operation to their children.

Alternatively you may look for real world code that is accessible online and demonstrate the points using the example. (I.e. you submit a text with a description and links into the code.)

Analysis Object Model for the Game Appointments Scheduler

You have developed a little program to schedule appointments for playing games. The program was first only used for scheduling Skat games (3 players) but as some British friends became interested you added scheduling of appointments for Bridge games (4 players) as well. Above you see the Analysis Object Model. In your repository you find a class diagram that shows more details.

Your task is now:

• Discuss the abstractness and stability of the classes in the AOM. (For definitions see slide 8 of the design patterns lecture)
• Comment on the dependencies and the impact they have on the possibility to reuse parts of the model.
• Remove the dependency from the GameAppointment to the Forms by introducing the Observer pattern.
  • Which classes are observers? Which class(es) are subject(s)?
  • Edit the model accordingly. Add the required types and operations.
  • Add notes for new operations. Adapt the existing notes.
• Describe in one to two sentences how the introduction of the pattern improved the model and maybe how it made it worse.

Optionally you can do more:

• Create an interface for the GameAppointment that contains only read-access methods and let the forms use it.
• Add an AppointmentList object that creates the GameAppointments and let the controllers use it.
• Create a component diagram with one component for each boundary and each controller plus one component for all entities together. (5 components in total. You can keep the components as black boxes.)
• The port to connect forms and entities contains two interfaces. Which? Add ports and interfaces to those components.
• Create as well the port to connect controllers and the entities.
• Finally introduce a new OverviewForm that shows all appointments and their state. You might need to introduce another instance of the observer pattern. Adapt the class and the component diagram accordingly.

This task introduces a pattern that we will not present in the lecture. Yet, the goal of this task is not so much to introduce you into just another pattern but to give an example where the use of abstract principles can help you to decide whether a pattern is appropriate.

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? Explain in one or two sentences.
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.