Design Patterns - Questions

1. Design Patterns Discussion

1. Are design patterns a form of reuse? If so, what are you reusing? Ans. Design patterns allow you to reuse architecture and design. 2. Do design patterns provide architecture? Ans. No. You might say that design patterns provide micro-architecture but architecture refers to how the components of the system as a whole work together. Design patterns offer solutions to specific problems that are only part of the whole system. 3. What makes coupling "loose"? Ans. An object is loosely coupled if it is dependent on only a few other objects and/or the dependencies are abstract. For example, in the Observer design pattern the observed object is loosely coupled to the observer objects not because the observed object has few dependencies (there might be hundreds of observers). The observed object is loosely coupled to its observers because it is dependent only on the abstract interface Observer. 4. How are design patterns different from programming idioms? Ans. Idioms are reoccurring solutions to common programming problems. For example, here is the Java idiom for ending a program when the window is closed:
addWindowListener( new WindowAdapter() { public void windowClosing(WindowEvent e) { System.exit(0); } } );

Idioms are low-level patterns specific to a programming language. Design patterns are high-level and language independent. During implementation you look for idioms. During design you look for patterns. 5. How are design patterns different from frameworks? Ans. Frameworks are semi-complete applications. For example, the Microsoft Foundation Classes (MFC's) are a framework for writing C++ windows applications. Frameworks may include design patterns, but aren't by themselves design patterns. Design patterns are more general than frameworks. A framework can't be used to generate an architecture or solution to a problem-the framework is the architecture. Design patterns are generative. This means that you can generate a specific solution from a design pattern. 6. How are design patterns different from principles and strategies? For example, 1

"components should have strong cohesion and weak coupling" is an object oriented design principle. Ans. Principles and strategies are more general than design patterns. The same principle or strategy can be applied to many different types of problems. A design pattern solves a specific problem. A principle doesn't include all the elements of a design pattern. For example, a principle doesn't explain how to achieve the desired state. 7. How are design patterns different from algorithms and data structures? Ans. There is a different focus. Algorithms and data structures are focused on time and space efficiencies. Design patterns are focused on architectural issues such as maintainability and extendibility. Algorithms and data structures provide solutions to computational problems like sorting and searching. Patterns provide solutions to architectural problems like interchanging sorting algorithms without disrupting other code. 8. Is a hash table a design pattern? Ans. No. A hash table is a data structure. A hash table is a specific solution, not a design generalization that can be applied in different contexts. A design pattern is more abstract than a data structure. 9. How are design patterns different from class libraries? Ans. Class libraries are specific solutions written for a specific environment/language. You use class libraries. You apply design patterns. 10. Can any design solution be a design pattern? Ans. No. To be a design pattern the problem it solves should be reoccurring. The solution should also have been tested on multiple problems in different contexts. The design pattern should have undergone some scrutiny. Design patterns form an exclusive club. Membership is reserved for crusty old solutions that have been around for awhile.

2. Overview
1. Every Design Pattern allows the developer to vary different parts of a design. Complete the following table: Purpose creational Design Pattern Abstract Factory Families of objects that get created Structural Adapter Interface of class structural 2 Composite Structure and composition of an object Aspect(s) That Can Vary

Purpose

Design Pattern

Aspect(s) That Can Vary

behavioral

Observer

Dependents of object, kind of dependents

behavioural

Chain of Responsibility Flyweight

Object that can fulfill a request

creational

Amount of instances of a particular class creational Singleton The sole instance of a class

creational

Factory Method

Class of object that is created

structural

Proxy

How an object is accessed, its location

structural

Facade Internal details of subsystem

behavioural

Visitor

Operations that can be applied to object(s) without changing their class(es)

2. What Design Pattern would you use together with the Composite pattern, and why? Ans. The Visitor, to compute something over the whole tree. 3. Can an Adapter be used to reduce the complexity of an application? Ans. An Adapter is used to adapt the interface of a class or object. The Facade pattern however defines a general solution to encapsulate complex functionality. 4. Are the Singleton and the Flyweight pattern related? if yes, how? if not, why? Ans. No, not really. There are multiple instantiations of the object implementing the flyweight pattern. Although the functionality of the object is only available once. 5. Review your answers to the exercises of Day 1, the drawing Editor. Did you use some design patterns intuitively? Would it be better to use design patterns in some cases? 3

6. Review your answers to the exercises of Day 1, the File System. Are there any design patterns used? 7. Why does the update method in the Observer interface in some cases include a reference to the object being observed? Doesn't the observer know what object it is observing? Ans. In some cases the Observer depends on more than one subject. For example, a spreadsheet may depend on more than one data source. So it needs to know which subject changed and caused the notification. Page 297. 8. Do design patterns have to be object oriented (i.e. rely on inheritance and/or polymorphism)? Ans. No. For example, the singleton design pattern isn't object oriented. However, most design patterns are object oriented. One explanation is that object oriented design is harder and therefor more dependent on documented solutions. Another explanation is that object oriented techniques are an essential part of good design. 9. This question describes an imaginary situation and you are to decide which design pattern or patterns apply. Imagine your surprise this Christmas when, instead of traditional presents under the tree, you find boxes with labels and handles. When you pull a handle a present comes out. The present is unique but it matches the category label on the box. Some boxes are labeled with age ranges. These boxes will produce different types of presents, but they all match the age range. What design pattern or patterns are evident in this scene? Ans. The boxes represent two design patterns: Factory Method and Abstract Factory. The boxes with age ranges represent the Abstract Factory class because each product is related to a family of products. The box with a single label represents the the Factory Method design pattern. 10. If you write a program that includes an efficient novel solution to a common design problem can you declare it a design pattern without applying the solution to other programming problems? Ans. No. What's missing is experience with the pattern in different contexts. Efficient novel solutions to design problems can't be declared design patterns until they have been applied to different programming problems. A design pattern is a solution to a design problem but must also include the consequences and trade-offs in using the pattern in possibly different ways. 4

11. Design patterns, architecture styles and frameworks are all very similar. How do each of these techniques compare in terms of the type of reuse they enable? Ans. Design patterns enable design reuse. Architecture styles enable architecture reuse and frameworks enable architecture and application logic reuse.