Class (1)
Download as PPT, PDF0 likes728 views
This document provides an introduction to design patterns. It defines what a design pattern is, discusses common types and classifications of patterns. It explains the benefits of using patterns such as reducing time to design applications and avoiding problems from inexperienced design decisions. Examples of specific patterns are described in detail including Elements of Identification, Catalytic Scenarios, and Mutable Code. Principles of object-oriented design like programming to an interface are covered. The differences between class and interface inheritance and composition vs inheritance are explained.
Class (1)
- 1. Software Engineering Design Patterns -- Introduction Mira Balaban Department of Computer Science Ben-Gurion university Based on slides of: 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, 2005 Design Patterns – introduction 1
- 2. Sources: 1. Classical text: Design Patterns: Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides, (GoF), 1995 2. Java Design Patterns – A Tutorial, J.W. Cooper, 2000. 3. Applied Java Patterns, S. Stelting, O. Maassen, 2002. 4. Patterns home page: http://hillside.net/patterns/ 5. Yearly conferences: Patterns Languages of Programs. http://hillside.net/conferences/plop.htm Software Engineering, 2005 Design Patterns – introduction 2
- 3. What is a Pattern? (R. Whitney) "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice“ "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 Software Engineering, 2005 Design Patterns – introduction 3
- 4. What is a Pattern? (R. Whitney) "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/ Software Engineering, 2005 Design Patterns – introduction 4
- 5. Example: A Place To Wait (Alexander 1977) The process of waiting has inherent conflicts in it. The context: Waiting for doctor, airplane etc. requires spending time hanging around doing nothing Can not enjoy the time since you do not know when you must leave Classic "waiting room" • • • • Dreary little room People staring at each other Reading a few old magazines Offers no solution Software Engineering, 2005 Design Patterns – introduction 5
- 6. 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 Software Engineering, 2005 Design Patterns – introduction 6
- 7. 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" Software Engineering, 2005 Design Patterns – introduction 7
- 8. 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. 391406, Pattern Languages of Program Design 2, Addison Wesley, 1996 Software Engineering, 2005 Design Patterns – introduction 8
- 9. 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 Software Engineering, 2005 Design Patterns – introduction 9
- 10. Example: A Pattern Language for the Preparation of Software Demonstrations (Coram 1996) The patterns: Element Identification 2. Catalytic Scenarios 3. Mutable Code 4. Prototyping Languages 5. Lightweight User Interfaces 6. Judicious Fireworks 7. Archive Scenarios 1. 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 Software Engineering, 2005 Design Patterns – introduction 10
- 11. 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 Software Engineering, 2005 Design Patterns – introduction 11
- 12. 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) Software Engineering, 2005 Design Patterns – introduction 12
- 13. 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 Software Engineering, 2005 Design Patterns – introduction 13
- 14. 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 Software Engineering, 2005 Design Patterns – introduction 14
- 15. 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 Software Engineering, 2005 Design Patterns – introduction 15
- 16. 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 Software Engineering, 2005 Design Patterns – introduction 16
- 17. 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) Software Engineering, 2005 Design Patterns – introduction 17
- 18. 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) Software Engineering, 2005 Design Patterns – introduction 18
- 19. 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 Software Engineering, 2005 Design Patterns – introduction 19
- 20. Benefits of Software Patterns (R. Whitney) By providing domain expertise patterns Reduce time to find solutions Avoid problems from inexpert design decisions Patterns reduce time to design applications Patterns are design chunks larger than objects Patterns reduce the time needed to understand a design Software Engineering, 2005 Design Patterns – introduction 20
- 21. 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 Software Engineering, 2005 Design Patterns – introduction 21
- 22. 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. However, 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 Software Engineering, 2005 Design Patterns – introduction 22
- 23. Becoming a Software Design Master (D.C. Schmidt) First learn the rules – e.g., the algorithms, data structures and languages of software Then learn the principles – e.g., structured programming, modular programming, object oriented programming, generic programming, etc. However, to become a master of software design, one must study the designs of other masters – These designs contain patterns that must be understood, memorized, and applied repeatedly There are hundreds of these patterns Software Engineering, 2005 Design Patterns – introduction 23
- 24. Stages of Design Pattern awareness (J. Vlissides) Acceptance Recognition Internalization (Cooper) benefit familiarity understanding initiation Ignorance consternation Software Engineering, 2005 Design Patterns – introduction 24
- 25. 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 Software Engineering, 2005 Design Patterns – introduction 25
- 26. Common Forms for Writing Design Patterns (R. Whitney) Alexander • Originated pattern literature GOF (Gang of Four) • Style used in Design Patterns text Portland Form • Form used in on-line Portland Pattern Repository http://c2.com/cgi/wiki?PortlandPatternRepository Coplien Software Engineering, 2005 Design Patterns – introduction 26
- 27. 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 Software Engineering, 2005 Design Patterns – introduction 27
- 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) Software Engineering, 2005 Design Patterns – introduction 28
- 29. GoF Design Patterns Classified (F. Tip) Software Engineering, 2005 Design Patterns – introduction 29
- 30. Principles of Object-Oriented Design (F. Tip) Program to an interface, not an implementation. Favor object composition over class inheritance. Software Engineering, 2005 Design Patterns – introduction 30
- 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 many languages (e.g., C++) don’t make this distinction, but Java does Software Engineering, 2005 Design Patterns – introduction 31
- 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 Software Engineering, 2005 Design Patterns – introduction 32
- 33. Mechanisms for Reusing Functionality (F. Tip) 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” Software Engineering, 2005 Design Patterns – introduction 33
- 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 Software Engineering, 2005 Design Patterns – introduction 34
- 35. Delegation (F. Tip) delegation is an alternative to inheritance: • two objects are involved: a receiving object delegates 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 Dobject, which needs to be initialized • C needs a forwarding method f() that calls f() on d Software Engineering, 2005 Design Patterns – introduction 35
- 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() ... } } Software Engineering, 2005 Design Patterns – introduction 36
- 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() ... } } Software Engineering, 2005 Design Patterns – introduction 37
- 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 Software Engineering, 2005 Design Patterns – introduction 38
- 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 Software Engineering, 2005 Design Patterns – introduction 39
- 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) Software Engineering, 2005 Design Patterns – introduction 40
- 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 Software Engineering, 2005 Design Patterns – introduction 41
- 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 Software Engineering, 2005 Design Patterns – introduction 42
- 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 Software Engineering, 2005 Design Patterns – introduction 43