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.)
|8 (+9) points|
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:
GameAppointmentto the Forms by introducing the Observer pattern.
Optionally you can do more:
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.
Mediatordefines all possible interactions between the colleagues.
ConcreteMediatorthen implements these interactions between the
ConcreteColleguewants to communicate with another
ConcreteColleguethey will not communicate directly, but through the
ConcreteColleaguesbut only between the
Your task is now: