Release date: Wednesday, 26.06.13 - Due date: Monday, 01.07.13, 23:59

So, it's the cloud BAKERY 2100 again . You can find the incomplete class diagrams as well as the use case diagram and the analysis object model in the file A9T01_DesignPattern in your repository. In the following we ask for three design patterns. It is enough, when you give us the classes and the relationships between the classes. Fields and methods are not required.

a) One developing engineer of the “cloud BAKERY 2100” found out, that you can compose bread types to tasty new bread types. (You just need to combine the ingredients proportionally.) Which design pattern do you suggest to implement this? Complete the class diagram and explain in one or two sentences why you have chosen the design pattern:

Classes for tasty new bread types

b) The OrderBakedGoodsController collaborates with the CreditCardCompanyInterface, but unfortunately an important Bank only offers the LegacyBankingInterface. Which design pattern solves this situation? Complete the class diagram and explain in one or two sentences why you have chosen the design pattern:

Dealing the the important legacy bank

c) In the analysis object model the CallMaintainerController depends on the MaintenanceInterface, but we don’t want to have dependencies from controllers to the user interface. Which design pattern (or even something simpler) solves this situation? Complete the class diagram and explain in one or two sentences why you have chosen the design pattern:

Removing dependencies from controller to UI

d) If a system has a “high” and a “low” layer, which layer is allowed to access which? Note at each type in the last class diagram, whether it belongs to “high” or “low”. 

• Describe the idea of Information Hiding. What are the expected benefits of Information Hiding? (2-3 sentences)
• Following Design by Contract, interface specifications should be extended with additional assertions. Name the three kinds of assertions and describe each in 1-2 sentences.
• What does it mean for the three kinds of assertions, if B is a subclass of A and both contain a method m().

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”. You learned 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.

Some tips:

More information:

• Assume C is a subtype of B and B is a subtype of A (e.g. C extends B and B implements A).
  → Compare the strength of the conditions “x is of type A”, “x is of type B”, “x is of type C”!
• Assume now that T is a subtype of S. We expect T to fulfill all contracts of S, especially the methods in T should “demand no more” and “promise no less”.
• In the occult OO language that we are discussing this is the only restriction on the types of parameters and return types.
• Given that S has a method B m(B x) and m is overridden in T.
  → Which of the following signatures would be allowed for m in T:
  1. A m(B x)
  2. C m(B x)
  3. B m(A x)
  4. B m(C x)
  5. A m(C x)
  6. C m(A x)
• Maybe it helps you to meditate about the following code: S s = new T(); B input = new B(); B output = s.m(input);
• → Explain how this could improve the Builder Pattern (Slide 50) a bit.

Historical side note: The implications of substitutability on parameter and return types was already discussed before Barbara H. Liskov and Jeanette M. Wing suggested their criterion for substitutability. Nevertheless, it is interesting that behavioral subtyping implies the older criteria for subtyping of functions.