Software Engineering Design Patterns -- Introduction

1. Software EngineeringDesign Patterns -- Introduction Based on slides of: Mira Balaban Department of Computer Science Ben-Gurion university F. Tip, J. Vlissides, J. Cooper, IBM T J Watson Research Center. R. Whitney, San-Diego State University. D.C. Schmidt, Vanderbilt University. Software Engineering 2011 Department of Computer Science Ben-Gurion university

2. Sources • Classical text:Design Patterns: Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides, (GoF), 1995 • Java Design Patterns – A Tutorial, J.W. Cooper, 2000. (available online) • Applied Java Patterns, S. Stelting, O. Maassen, 2002. • Patterns home page: http://hillside.net/patterns/

3. What is a Pattern? • The term design pattern was coined in the mid-1970’s by Christopher Alexander, an architect, who abstracted common design patterns in architecture and formalized a way of describing the patterns in a “pattern language.” • A design pattern addresses botha problem that occurs repeatedly in our environment and the core of the solutionto that problem—but at a level of generality that the solution can be applied many times without ever being the same in its particulars.

4. What is a Pattern? • "Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution" Christopher Alexander on architecture patterns A Pattern Language, Christopher Alexander, 1977 • "Patterns are not a complete design method; they capture important practices of existing methods and practices uncodified by conventional methods" James Coplien Software Patterns, James Coplien, 1996, 2000, http://www1.belllabs.com/user/cope/Patterns/WhitePaper/

5. Example: A Place To Wait (Alexander 1977) Fundamental problem: • How to spend time wholeheartedly and • Still be on hand when doctor, airplane etc arrive The solution: • Fuse the waiting with other activity that keeps them in earshot • Playground beside Pediatrics Clinic • Horseshoe pit next to terrace where people waited • Allow the person to become still meditative • A window seat that looks down on a street • A protected seat in a garden • A dark place and a glass of beer • A private seat by a fish tank

6. Example: A Place To Wait (Alexander 1977) The Solution: "In places where people end up waiting create a situation which makes the waiting positive. Fuse the waiting with some other activity - newspaper, coffee, pool tables, horseshoes; something which draws people in who are not simple waiting. And also the opposite: make a place which can draw a person waiting into a reverie; quiet; a positive silence“ The active part might have a window on the street - STREET WINDOWS (164), WINDOW PLACE (180), a cafe - STREET CAFE (88), games, positive engagements with the people passing by - OPENING TO THE STREET (165). The quiet part might have a quiet garden seat - GARDEN SEAT (176), a place for people to doze SLEEPING IN PUBLIC (94), perhaps a pond with fish in it - STILL WATER (71). To the extent that this waiting space is a room, or a group of rooms, it gets its detailed shape from LIGHT ON TWO SIDES OF EVERY ROOM (159) and THE SHAPE OF INDOOR SPACE (191).

7. Example: Chicken and Egg (Anthony 1996) The Problem • Two concepts are each a prerequisite of the other • To understand A one must understand B • To understand B one must understand A • A "chicken and egg" situation Patterns for Classroom Education, Dana Anthony, pp. 391- 406, Pattern Languages of Program Design 2, Addison Wesley, 1996

8. Example: Chicken and Egg (Anthony 1996) Constraints and Forces • First explain A then B Everyone would be confused by the end • Simplify each concept to the point of incorrectness to explain the other one People don't like being lied to The Solution • Explain A & B correctly by superficially • Iterate your explanations with more detail each iteration

9. Example:A Pattern Language for the Preparation of Software Demonstrations(Coram 1996) The patterns: • Element Identification • Catalytic Scenarios • Mutable Code • Prototyping Languages • Lightweight User Interfaces • Judicious Fireworks • Archive Scenarios Demo Prep: A Pattern Language for the Preparation of Software Demonstrations, Todd Coram, pp. 407-416, Pattern Languages of Program Design 2, Addison Wesley, 1996

10. Pattern 1:Element Identification(Coram 1996) The Problem: Selecting the right features to demo is a critical part of keeping the customer's confidence The Context • Have requirements • Working on demo to easy customers doubts about committing to or continuing with the software project Forces • Need to demonstrate your ability to deliver "things that work" • Need to show some level of functionality • Customer wants to see the product's face - the GUI • If customer is not happy with the demo, they are not likely to like the end product • Demos build confidence and create anticipation

11. Pattern 1:Element Identification(Coram 1996) The Solution: • Identify key areas that concern the customer Talk to the customer Listen carefully • Stay away from excessive animations or other visual embellishments Unless the product is a game, the product is to help the customer get some work done not to entertain people • The product's face can be shown through Lightweight User Interface (pattern 5) • Functionality can be addressed by Prototyping Languages (pattern 4)

12. Pattern 2:Catalytic Scenarios (Coram 1996) The Problem: • The customer has specified what they think they want • You don't want to build the wrong thing The Context Starting a project to develop software based on requirements and specification that have already been agreed on The Forces • Customer may not really know what they want • Requirements may not accurately reflect customer's requirements • Requirements may be ambiguous • Customer expects to be given vision of the finished product • Demos consume developer's resources

13. Pattern 2:Catalytic Scenarios (Coram 1996) The Solution: • Use demonstrable scenarios as a catalyst to open a dialogue between you and the customer • If the specs are ambiguous - develop alternative scenarios • Do not demonstrate capabilities that will be hard to incorporate into your design • If you do not want to change the spec make sure the demo scenarios follow the spec • Keep demo scenarios simple and short

14. Pattern 3:Mutable Code (Coram 1996) The Problem: How much code should you write for the demo? The Context You have identified your Catalytic Scenarios and are evaluating the amount of effort required to develop them The Forces • Some demo code • Can not be used in the end product • Should not be used in the end product • Development time for demo impacts product development • Customer does not like to pay for developing something twice

15. Pattern 3:Mutable Code (Coram 1996) The Solution: • Build modifiable code • Use tools that support a high level of abstraction • GUI builders • Scripting languages • Write as little code as possible for the demo • Use as much real code as you can • If you build screens then use Lightweight User Interfaces • Prototyping Languages (pattern 4) discusses integrating demo code into end product

16. Patterns of Learning(D.C. Schmidt) • Successful solutions to many areas of human endeavor are deeply rooted in patterns – An important goal of education is transmitting patterns of learning from generation to generation • Learning to develop good software is similar to learning to play good chess

17. Becoming a Chess Master(D.C. Schmidt) • First learn the rules – e.g., names of pieces, legal movements, chess board geometry and orientation, etc. • Then learn the Principles – e.g., relative value of certain pieces, strategic value of center squares, power of a threat, etc. • To become a master of chess, one must study the games of other masters – These games contain patterns that must be understood, memorized, and applied repeatedly • There are hundreds of these patterns

18. What are design patterns? (J.W. Cooper) • Recurring solutions to design problems you see over and over. (Alpert et al, 1998) • A set of rules describing how to accomplish certain tasks in the realm of software development. (Pree, 1994) • Focus on reuse of recurring architectural design themes (Coplien and Schmidt, 1995) • Address a recurring design problem that arises in a specific context and presents a solution to it (Buschmann. et al, 1996) • Identify and specify abstractions that are above the level of single classes or instances, or of components. (GoF)

19. More Paradigms of design patterns • Problem Analysis (Fowler) • Enterprise systems (Fowler) • Responsibility assignment in system design (Larman) • User interfaces. • Web site construction. • Software design (GoF, Coplien, and others)

20. What is a Software design pattern? (F. Tip) • Related question: what is the difference between experienced and inexperienced software designers? experienced designers : • know from experience what works and what doesn’t • able to recognize “standard” design problems and apply “proven” solutions to them • Definition of a software design pattern: a description of communicating classes and objects that are customized to solve a general design problem in a particular context

21. Stages of Design Pattern awareness(J. Vlissides) benefit familiarity understanding initiation consternation Ignorance

22. Learn to apply design patterns to the design process(J. Vlissides) • find the right patterns • understand (un)applicability • see when and how to bend a pattern • evaluate design trade-offs effectively • Learn by (counter) example

23. Software Design Patterns - Motivation • OOD methods emphasize design notations • Fine for specification, documentation • But OOD is more than just drawing diagrams • Good draftsmen good designers • Good OO designers rely on lots of experience • At least as important as syntax • Most powerful reuse is design reuse • Match problem to design experience

24. Recurring Design Structures • OO systems exhibit recurring structures that promote • abstraction • Flexibility • Modularity • elegance • Therein lies valuable design knowledge • Problem: capturing, communicating, & applying this knowledge

25. Design Patterns • A design Pattern • abstracts a recurring design structure • comprises class and/or object • dependencies • structures • interactions • Conventions • names & specifies the design structure explicitly purify design experience

26. Elements of Design Patterns (F. Tip) • A design pattern has 4 elements: • a name (e.g, “Abstract Factory” or “Visitor”) • the problem that the pattern addresses • the solution: the program constructs that are part of the pattern • the consequences: the results and tradeoffs of applying the pattern • other factors: • problem & solution have been observed in practice • choice of implementation language important

27. Goals • Codify good design • distill & generalize experience • aid to novices & experts alike • Give design structures explicit names • common vocabulary • reduced complexity • greater expressiveness • Capture & preserve design information • articulate design decisions succinctly • improve documentation • Facilitate restructuring/refactoring • patterns are interrelated • additional flexibility

28. Classifying Design Patterns (F. Tip) • purpose: what a pattern does • creational: concerned with creation of objects • structural: related to composition of classes or objects • behavioral: related to interaction and distribution of responsibility • scope • class-level: concerned with relationship between classes and their subclasses • object-level: concerned with object relationship (more dynamic, may be changed at run-time)

29. GoF Design Patterns Classified (F. Tip)

30. Principles of Object-Oriented Design(F. Tip) Program to an interface, not an implementation. Favor object composition over class inheritance.

31. Class vs. Interface Inheritance (F. Tip) • Class inheritance defines an object’s implementation in terms of another object’s implementation • mechanism for code & representation sharing • Interface inheritance describes when an object can be used in place of another (subtyping) • many languages (e.g., C++) don’t make this distinction, but Java does An object's class defines how the object is implemented. The class defines the object's internal state and the implementation of its operations. An object's type only refers to its interface—the set of requests to which it can respond. An object can have many types, and objects of different classes can have the same type

32. Class vs. Interface Inheritance (2) (F. Tip) • benefits of class inheritance • extend an application’s functionality by reusing functionality in parent classes • lets you get new implementations almost for free, inheriting most of what you need from existing classes • benefits of interface inheritance • clients remain unaware of specific types of objects they use, and of the classes that implement these objects • using interface inheritance greatly reduces dependencies between subsystems • reduces the impact of changes

33. Mechanisms for Reusing Functionality (F. Tip)Inheritance versus Composition • class inheritance: define implementation of one class in terms of another • often referred to as white-box reuse: internals of parent class visible to extending class “class inheritance breaks encapsulation” • object composition: compose objects to get new, more complex functionality • implemented by giving objects references to other objects; access these objects via interfaces • requires that objects have well-defined interfaces • often called black-box reuse: no internal details of objects are visible to the class that uses them “composition does not break encapsulation”

34. Pros & Cons of Class Inheritance (F. Tip) • Advantages: • directly supported by the programming language, hence easy to use • makes it easy to modify the reused implementation (by simply overriding a few methods) • Disadvantages: • cannot change inherited functionality at run-time, because inheritance is fixed at compile-time • parent classes define at least part of their subclasses’ physical representation, and subclasses are exposed to details of their parent’s implementation • implementation of subclass becomes very tightly coupled with implementation of parent • change in parent is likely to require changes in subclass

35. Delegation (F. Tip) • delegation is an alternative to inheritance: • two objects are involved: a receiving objectdelegates an operation to its delegate • analogy: a subclass that defers a request to its parent class • suppose an object of type C wants to delegate a method f() to an object of type D: • class D defines method f() • class C needs to contain a reference field d to a D-object, which needs to be initialized • C needs a forwarding method f() that calls f() on d

36. Delegation: Example (F. Tip) class Window delegates its area() operation to a Rectangle instance public class Rectangle { private int width; private int height; public int area(){ return width * height; } } public class Window { private Rectangle rect; public int area(){ return rect.area(); } } public class WindowClient { void someOperation(Window w){ ... w.area() ... } }

37. (Ab)use inheritance for the same purpose(F. Tip) public class Rectangle { private int width; private int height; public int area(){ return width * height; } } public class Window extends Rectangle { private Rectangle rect; // method area() inherited from superclass } public class WindowClient { void someOperation(Window w){ ... w.area() ... } }

38. Why use delegation? (F. Tip) • inheritance can be more convenient: • only define method f() once • no need to forward calls • somewhat more efficient • however, it is less flexible: • cannot change the implementation of f() after creating the object • in languages with single inheritance, you can only inherit methods from one superclass

39. True delegation (F. Tip) • with inheritance, the method in the superclass can use dynamic dispatch to invoke methods in a subclass • with delegation, this requires some extra work: • pass receiving object’s this pointer as an argument to the delegate • delegate invokes methods on this reference when it needs to invoke methods on receiving object • this form of delegation is called true delegation • for an example of true delegation, see the “State” design pattern

40. When to use inheritance? (F. Tip) • generally speaking, use inheritance for: • is-a relationships that don’t change over time • situations where the class containing the actual operation is abstract • generally speaking, use delegation for: • has-a, part-of relationships • is-a-role-played-by relationships • relationships that change over time • situations where multiple inheritance would be needed (if language doesn’t allow MI)

41. Designing for change (F. Tip) • many design patterns introduce flexibility to avoid common causes of redesign such as: • creating an object by specifying a class explicitly • dependence on specific operations • dependence on hardware/software platform • dependence on object representations or implementations • algorithmic dependencies • tight coupling • extending functionality by subclassing • inability to alter classes conveniently

42. Designing for change (R. Whitney) Some common design problems that GoF patterns that Address: • Creating an object by specifying a class explicitly Abstract factory, Factory Method, Prototype • Dependence on specific operations Chain of Responsibility, Command • Dependence on hardware and software platforms Abstract factory, Bridge • Dependence on object representations or implementations Abstract factory, Bridge, Memento, Proxy

43. Designing for change (R. Whitney) • Algorithmic dependencies Builder, Iterator, Strategy, Template Method, Visitor • Tight Coupling Abstract factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer • Extending functionality by subclassing Bridge, Chain of Responsibility, Composite, Decorator, Observer, Strategy • Inability to alter classes conveniently Adapter, Decorator, Visitor

44. GOF: Describing Design Patterns • Pattern Name and Classification The pattern's name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary. • Intent A short statement that answers the following questions: What does the design pattern do? What is its rationale and intent? What particular design issue or problem does it address? • Also Known As Other well-known names for the pattern, if any. • Motivation A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. The scenario will help you understand the more abstract description of the pattern that follows. • Applicability What are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern can address? How can you recognize these situations? • Structure A graphical representation of the classes in the pattern using a notation based on the Object Modeling Technique , interaction diagrams to illustrate sequences of requests and collaborations between objects.

45. GOF: Describing Design Patterns • Participants The classes and/or objects participating in the design pattern and their responsibilities. • Collaborations How the participants collaborate to carry out their responsibilities. • Consequences How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently? • Implementation What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues? • Sample Code Code fragments that illustrate how you might implement the pattern in C++ or Smalltalk. • Known Uses Examples of the pattern found in real systems. We include at least two examples from different domains. • Related Patterns What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?

46. Example: The Model/View/Controller (MVC) • MVC consists of three kinds of objects. • The Model is the application object • the View is its screen presentation • the Controller defines the way the user interface reacts to user input. • Before MVC, user interface designs tended to lump these objects together. • MVC decouples them to increase flexibility and reuse. • MVC decouples views and models by establishing a subscribe/notify protocol between them. • A view must ensure that its appearance reflects the state of the model. • Whenever the model's data changes, it notifies views that depend on it. • In response, each view gets an opportunity to update itself. • This approach lets you attach multiple views to a model to provide different presentations. • You can also create new views for a model without rewriting it.

47. Example: The Model/View/Controller (MVC) • Example: a model and three views. (controllers are not shown) • The model contains some data values, and the views defining a spreadsheet, histogram, and pie chart display these data in various ways. • The model communicates with its views when its values change, and the views communicate with the model to access these values.

48. Example: The Model/View/Controller (MVC) • This example reflects a design that decouples views from models. • The design is applicable to a more general problem: decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others. • This more general design is described by the Observer design pattern. • Another feature of MVC is that views can be nested. • For example, a control panel of buttons might be implemented as a complex view containing nested button views. • The user interface for an object inspector can consist of nested views that may be reused in a debugger.

49. Example: The Model/View/Controller (MVC) • MVC supports nested views with the CompositeView class, a subclass of View. • CompositeView objects act just like View objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views. • This design is applicable to a more general problem, which occurs whenever we want to group objects and treat the group like an individual object. • This more general design is described by the Composite design pattern. • It lets you create a class hierarchy in which some subclasses define primitive objects (e.g., Button) and other classes define composite objects that assemble the primitives into more complex objects.

50. Example: The Model/View/Controller (MVC) • MVC lets you change the way a view responds to user input without changing its visual presentation. • You might want to change the way it responds to the keyboard, for example, or have it use a pop-up menu instead of command keys. • MVC encapsulates the response mechanism in a Controller object. • There is a class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one. • A view uses an instance of a Controller subclass to implement a particular response strategy; • to implement a different strategy, simply replace the instance with a different kind of controller. • It's even possible to change a view's controller at run-time to let the view change the way it responds to user input. • For example, a view can be disabled so that it doesn't accept input simply by giving it a controller that ignores input events.