Design Patterns. Comp2110 Software Design. Department of Computer Science Australian National University. Second Semester

Transcription

1 Design Patterns Comp2110 Software Design Department of Computer Science Australian National University Second Semester

2 What is a Design Pattern? Current use comes from the work of the architect Christopher Alexander Alexander studied ways to improve the process of designing building and urban areas Each pattern is a three-part rule, which expresses a relation between a certain context, a problem and a solution. Hence, the comman defintion of a pattern: A sollution to a problem in a context. Patterns can be applied to many different areas of human endeavor, including software development 2

3 What is a Design Pattern? Definition: "A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts and presents a wellproven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate." [Buschmann]. 3

4 What is a Design Pattern? continued A design pattern is a way of reusing abstract knowledge about a problem and its solution A pattern is a description of the problem and the essence of its solution A pattern should be sufficiently abstract to be reused in different settings A pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts. Patterns often rely on object characteristics such as inheritance and polymorphism 4

5 What is a Design Pattern? continued design pattern is a widely accepted solution to a recurring design problem in OOP a design pattern describes how to structure classes to meet a given requirement provides a general blueprint to follow when implementing part of a program does not describe how to structure the entire application does not describe specific algorithms focuses on relationships between classes 5

6 Why Design Patterns? Designing object-oriented software is hard and designing reusable object-oriented software is even harder. -Erich Gamma Experienced designers reuse solutions that have worked in the past Well-structured object-oriented systems have recurring patterns of classes and objects Knowledge of the patterns that have worked in the past allows a designer to be more productive and the resulting designs to be more flexible and reusable 6

7 In general, patterns have the following characteristics: A pattern describes a solution to a recurring problem that arises in specific design situations. Patterns are not invented; they are distilled from practical experience. Patterns describe a group of components (e.g., classes or objects), how the components interact, and the responsibilities of each component. That is, they are higher level abstractions than classes or objects. 7

8 Patterns provide a vocabulary for communication among designers. The choice of a name for a pattern is very important. Patterns help document the architectural vision of a design. If the vision is clearly understood, it will less likely be violated when the system is modified. Patterns provide a conceptual skeleton for a solution to a design problem and, hence, encourage the construction of software with well-defined properties Patterns are building blocks for the construction of more complex designs. 8

9 Patterns help designers manage the complexity of the software. When a recurring pattern is identified, the corresponding general solution can be implemented productively to provide a reliable software system. 9

10 Descriptions of Patterns Typically a pattern will be described with a schema that includes at least the following three parts: 1. Context The Context section describes the situation in which the design problem arises. 2. Problem The Problem section describes the problem that arises repeatedly in the context. In particular, the description describes the set of forces repeatedly arising in the context. A force is some aspect of the problem that must be considered when attempting a solution. Example types of forces include: requirements the solution must satisfy (e.g., efficiency) constraints that must be considered (e.g., use of a certain algorithm or protocol) desirable properties of a solution (e.g., easy to modify) 10

11 Descriptions of Patterns continued Forces may complementary (i.e., can be achieved simultaneously) or contradictory (i.e., can only be balanced). 3. Solution The Solution section describes a proven solution to the problem. The solution specifies a configuration of elements to balance the forces associated with the problem. A pattern describes the static structure of the configuration, identifying the components and the connectors (i.e., the relationships among the components). A pattern also describes the dynamic runtime behavior of the configuration, identifying the control structure of the components and connectors. 11

12 What makes a good pattern? This is a good pattern because: It solves a problem: Patterns capture solutions, not just abstract principles or strategies. It is a proven concept: Patterns capture solutions with a track record, not theories or speculation. The solution isn't obvious: Many problem-solving techniques (such as software design paradigms or methods) try to derive solutions from first principles. The best patterns generate a solution to a problem indirectly -- a necessary approach for the most difficult problems of design. 12

13 It describes a relationship: Patterns don't just describe modules, but describe deeper system structures and mechanisms. The pattern has a significant human component (minimize human intervention): All software serves human comfort or quality of life; the best patterns explicitly appeal to aesthetics and utility. 13

14 Pattern elements Patterns have in general four parts: Pattern Name: Having a concise, meaningful name for a pattern improves communication among developers. Problem: What is the problem and context where we would use this pattern? What are the conditions tha must be met before this pattern should be used? 14

15 Solution: A description of the elements that make up the design pattern Emphasizes their relationships, reponsibilities and collaborations Not a concrete design or implementation; rather a template for a design solution that can be instantiated in different ways Consequences: The pros and cons of using the pattern Includes impacts on reusability, portability, extensibility The results and trade-offs of applying the pattern 15

16 Design Pattern Space Creational patterns Deal with initializing and configuring of classes and objects. Structural patterns Deal with decoupling interface and implementation of classes and objects. Behavioral patterns Deal with dynamic interactions among societies of classes and objects. 16

17 Types of Patterns Creational Patterns Abstract Factory Buider Factory Method Prototype Singleton Behavioral Patterns Observer Visitor Command State Iterator Mediator Chain of Responsibility Structural Patterns Adapter Façade Proxy Composite Bridge Decorator 17

18 The Composite Pattern Definition Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. This is called recursive composition. 18

19 The classes and/or objects participating in the Composite pattern are: Component: declares the interface for objects in the composition. implements default behavior for the interface common to all classes, as appropriate. declares an interface for accessing and managing its child components. (optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate. implements child-related operations in the Component interface. 19

20 Leaf represents leaf objects in the composition. A leaf has no children. defines behavior for primitive objects in the composition. Composite defines behavior for components having children. stores child components. 20

21 Client (CompositeApp) manipulates objects in the composition through the Component interface. 21

22 Composite Pattern Structure (UML Diagram) 22

23 Example: Book DocumentComponent Paragraph Composite Chapter Book Section 23

24 Typical Composite Object Structure might look like this: 24

25 Applicability Use the composite pattern when: You want to represent part-whole hierarchies of objects You want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in composite structure uniformly 25

26 Consequences Benefits It makes it easy to add a new kinds of components. It makes client simpler, since they do not have to know if they are dealing with a leaf or composite component. Liabilities It makes it harder to restrict the type of components of a composite. 26

27 Applicability Use the composite pattern when: You want to represent part-whole hierarchies of objects You want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in composite structure uniformly 27

28 Implementation issues A composite object knows its contained components, that is, its children. Should components maintain a reference to their parent component? Depend on application, having these references supports the chain of Responsibility pattern. 28

29 Implementation issues (Transparency versus Safety) Where should the child management methods (add(), remove(), getchild()) be declared? In the component class: Gives transparency, since all components can be treated the same But note safe, since clients can try to do meaningless things to leaf components at run time. In the composite class: Gives safety, since any attempt to perform child operation on a leaf component will be caught at compile time. But we loss transparency, since now leaf and composite components have different interfaces. 29

30 Transparent vs. Safe Class room exercise: 1. Draw class diagram for designing a transparent Composite Pattern interface. 2. Draw Class digram for designing a safe Composite Pattern interface. 30

31 The decision of whether the safe or transparent approach should be implemented is left to the system designer, who will make a decision in accordance with the particular characteristics of a system. 31

32 Implementation issues continued Should component maintain the list of components that will be used by a composite object? That is, Should this list be an instance variable of a component rather than composite. Better this part of composite and avoid wasting the space in every leaf object. Is child ordering important? Depend on application. 32

33 Who should delete components? Not a problem in Java. The garbage collector will come to the rescue. What is the best data structure to store components? Depend on application. 33

34 Example: Computer equipment Situation: Many type of manufactured systems, such as computer systems and stereo systems, are composed of individual components and subsystem that contain components. For example a computer system can have various chassis that contain components (hard-drive chassis, power supply chassis) and busses that contain cards. The entire system is composed of individual components (floppy drives, cd-rom drives), busses and chassis. 34

35 Solution: Use the Composite pattern 35

36 Sample code: The whole thing class Equipment { public: virtual ~Equipment() {} const string getname(){return name; } virtual float getpower() const = 0; virtual float getprice() const = 0; virtual void add(equipment *) {} virtual void remove(equipment *) {} protected: Equipment(const string & n) : name(n) {} private: string name; }; 36

37 Sample code: a leaf class FloppyDisk : public Equipment { public: FloppyDisk(const string & n, float pow, float pr) : Equipment(n), power(pow), price(pr) {} virtual ~FloppyDisk() {} virtual float getpower() const { return power; } virtual float getprice() const { return price; } private: float power; float price; }; 37

38 Sample code: another leaf class Card : public Equipment { public: Card(const string & n, float pow, float pr) : Equipment(n), power(pow), price(pr) {} virtual ~Card() {} virtual float getpower() const { return power; } virtual float getprice() const { return price; } private: float power; float price; }; 38

39 Sample code: Sub-equipment class CompositeEquipment : public Equipment { public: virtual ~CompositeEquipment() {} virtual float getpower() const {} virtual float getprice() const { float total = 0; for(list<equipment*>::const_iterator ptr = subeq.begin(); ptr!= subeq.end(); ++ptr) { total += (*ptr)->getprice();} return total; } virtual void add(equipment * item) { subeq.push_back(item);} virtual void remove(equipment *) {} protected: CompositeEquipment(const string & name) : Equipment(name) {} private: list<equipment*> subeq; }; 39

40 Sample code: pieces of sub-equipment class Chassis : public CompositeEquipment { public: Chassis(const string & n) : CompositeEquipment(n) {} virtual ~Chassis() {} }; class Bus : public CompositeEquipment { public: Bus(const string & n) : CompositeEquipment(n) {} virtual ~Bus() {} }; class Cabinet : public CompositeEquipment { public: Cabinet(const string & n) : CompositeEquipment(n) {} virtual ~Cabinet() {} }; 40

41 Sample code: main int main() { Cabinet * cabinet = new Cabinet("PC Cabinet"); Chassis * chassis = new Chassis("PC Chassis"); cabinet->add(chassis); Bus * bus = new Bus("MCA Bus"); bus->add(new Card("Sound Blaster", 100, )); bus->add(new Card("Graphics Accelerator", 100, )); chassis->add(bus); chassis->add(new FloppyDisk("3.5in Floppy", 7, 29.99)); cout <<"The price of " << chassis->getname() << endl <<"\tis " << chassis->getprice() << endl; } cout <<"The price of " << cabinet->getname() << endl <<"\tis " << cabinet->getprice() << endl; return 0; 41

42 Class Problem: Arithmetic Expression Apply Composite Pattern to work with arithmetic expressions built out of operators +,-, *, / and constants. The expressions that we are interested in are to evaluate arithmetic expressions, and print them. For example: (1 + 2) * 4 Result: (1+2)*4 = 12 4+(3*6) Result: 4+(3*6)=22 42

43 The Visitor Pattern Intent: Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates 43

44 Structure of Visitor Pattern 44

45 The classes and/or objects participating in this pattern are: Visitor: declares a Visit operation for each class of ConcreteElement in the object structure. The operation's name and signature identifies the class that sends the Visit request to the visitor. That lets the visitor determine the concrete class of the element being visited. Then the visitor can access the elements directly through its particular interface 45

46 ConcreteVisitor: implements each operation declared by Visitor. Each operation implements a fragment of the algorithm defined for the corresponding class or object in the structure. ConcreteVisitor provides the context for the algorithm and stores its local state. This state often accumulates results during the traversal of the structure. 46

47 Element: defines an Accept operation that takes a visitor as an argument. ConcreteElement: implements an Accept operation that takes a visitor as an argument 47

48 ObjectStructure: can enumerate its elements may provide a high-level interface to allow the visitor to visit its elements may either be a Composite (pattern) or a collection such as a list or a set 48

49 Visitor Define two class hierarchies one for object structure (or elements being operated on (nodes)) one for each operation family, called visitors that define operations on the elements create new operations by adding a new subclass to Visitor class hierarchy 49

50 Applicability When to Use Visitor: When an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes. When many distinct and unrelated operations need to be preformed on objects in an object structure and you want to avoid cluttering the classes with these operations. 50

51 When the classes defining the structure rarely change, but you often want to define new operations over the structure. 51

52 Consequences Visitors makes adding new operations easier If the structure involves many different classes then adding a new operation to the structure requires changing all those classes. Visitors gathers related operations, separates unrelated ones. 52

53 Adding new ConcreteElement classes is hard To add a new ConcreteElement you need to change all existing visitors. 53

54 Circularity Inherent in Visitor pattern: Visitor needs elements & elements need Visitor emanates from double dispatch In Java, it s much easier, don t have to worry about forward references, or quick compiles C++ strives for efficiency, at a cost in programmer expertise 54

55 Implementation issues A visitor must visit each element of the structure Who is responsible for traversing the structure? object structure -- most often an iterator the visitor -- problem: you will likely dupe traversal code in each concrete visitor 55

56 Class Problem: Arithmetic Expression Apply visitor pattern to work with arithmetic expressions built out of operators +,-, *, / and constants. The expressions that we are interested in are to evaluate arithmetic expressions, and print them. For example: (1 + 2) * 4 Result: (1+2)*4 = 12 4+(3*6) Result: 4+(3*6)=22 56

57 The Adapter Pattern The Adapter pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that could not otherwise because of incompatible interfaces. 57

58 The Adapter Pattern 58

59 Applicability Use the Adapter pattern when: You want to use an existing class and its interface does not match the one you need You want to create a reusable class that cooperates with unrelated or unforeseen classes, that is classes that don t necessarily have compatible interfaces You need to use several existing subclasses, but it s impractical to adapt their interface by subclassing everyone. An object adapter can adapt the interface of its parent class 59

60 Adapter has two forms: Class Adapter: Object Adapter: 60

61 Consequenses: A Class adapter uses inheritance so Only adapts a class and all its parents, not all its subclasses Lets Adapter override some of Adaptee s behavior Does not introduce an additional pointer indirection An object adapter uses object composition so Lets a single Adapter work with many Adaptees Makes it harder to override Adaptee behavior as the Adapter may not know with Adaptee it is working with 61

62 Class Problem 1. Adapt a ArrayedStack and LinkedStack to Stack interface. An abstract class STACK has four features push, pop, top and is_empty; it has two subclasses ArrayedStack and LinkedStack. Draw or sketch the solution on blackboard, relate to the UML diagram of Adapter pattern for class discussion. 2. A Queue is just like a stack, except that additions take place at the opposite end to removals. It's a first in first out (FIFO) structure where the stack is a last in first out (LIFO) structure. In fact what the boss wants is a new top class called DISPENSER, that has STACK and QUEUE as subclasses. Draw or sketch the solution on blackboard, relate to the UML diagram of Adapter pattern and Bridge pattern for class discussion separately. 62

63 The Bridge Pattern Decouple an abstraction from its implementation so that the two can vary independently. This allows the implementation to vary from its abstraction The abstraction defines and implements the interface All operations in the abstraction call method (s) its implementation object 63

64 Bridge Pattern UML Diagram 64

65 Applicability Use the Bridge pattern when: You want to avoid a permanent binding between an abstraction and its implementation Both the abstractions and their implementations should be independently extensible by subclassing Changes in the implementation of an abstraction should have no impact on the clients; that is, their code should not have to be recompiled You want to hide the implementation of an abstraction completely from clients (users) You want to share an implementation among multiple objects (reference counting), and this fact should be hidden from the client 65

66 Other issues Binding between abstraction & implementation In the Bridge pattern: An abstraction can use different implementations An implementation can be used in different abstraction Hide implementation from clients: In the Bridge pattern the client code can not access the implementation. For example, Java AWT uses Bridge to prevent programmer from accessing platform specific implementations of interface widgets, etc. 66

67 Example: Start with Window interface and two implementations: Now what do we do if we need some more types of windows: say IconWindow and DialogWindow? 67

68 The Bridge pattern provides a cleaner solution: IconWindow and DialogWindow will add functionality to or modify existing functionality of Window Methods in IconWindow and DialogWindow need to use the implementation methods to provide the new/modified functionality This means that the WindowImp interface must provide the base functionality for window implementation This does not mean that WindowImp interface must explicitly provide an iconifywindow method 68

69 The Decorator Pattern Intent: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality Changing the Skin of an Object 69

70 The Decorator Pattern Structure Run time structure 70

71 Applicability Use Decorator: To add responsibilities to individual objects dynamically and transparently For responsibilities that can be withdrawn When subclassing is impractical - may lead to too many subclasses Commonly used in basic system frameworks, for example, Windows, streams, fonts 71

72 Consequences More flexible than static inheritance Avoids feature laden classes high up in hierarchy Lots of little objects A decorator and its components are not identical So checking object identification can cause problems 72

73 Implementation Issues Keep Decorators lightweight Don't put data members in VisualComponent Have Decorator forward all component operations Three ways to forward messages Simple forward Extended forward Override 73

74 Example: Text Views A text view has the following features: side scroll bar Bottom scroll bar 3D border Flat border 74

75 Example continued This gives 12 different options: TextView TextViewWithNoBorder&SideScrollbar TextViewWithNoBorder&BottomScrollbar TextViewWithNoBorder&Bottom&SideScrollbar TextViewWith3DBorder TextViewWith3DBorder&SideScrollbar TextViewWith3DBorder&BottomScrollbar TextViewWith3DBorder&Bottom&SideScrollbar TextViewWithFlatBorder TextViewWithFlatBorder&SideScrollbar TextViewWithFlatBorder&BottomScrollbar TextViewWithFlatBorder&Bottom&SideScrollbar 75

76 How do you implement using Composite or Decorator patterns? Solution one - Use Object Composition 76

77 Solution 2 Use Decorator pattern Run time structure 77

78 The Prototype Pattern Intent: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. Prototype: Declares an interface for cloning itself ConcretePrototype: Implements an operation for cloning itself Client: Creates a new object by asking a prototype to clone itself 78

79 The Prototype pattern structure 79

80 Applicability Use the Prototype pattern when: A system should be independent of how its products are created, composed, and represented; and when the classes to instantiate are specified at run-time; or to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or when instances of a class can have one of only a few different combinations of state. It may be easier to have the proper number of prototypes and clone them rather than instantiating the class manually each time 80

81 Implementation Issues Using a prototype manager Implementing the Clone operation Initializing clones 81