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 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. 2

3 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 3

4 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. 4

5 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. 5

6 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. 6

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

8 Composite Pattern Structure (UML Diagram) 8

9 Example: Book DocumentComponent Paragraph Composite Chapter Book Section 9

10 Typical Composite Object Structure might look like this: 10

11 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 11

12 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. 12

13 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 13

14 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. 14

15 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. 15

16 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. 16

17 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. 17

18 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. 18

19 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. 19

20 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. 20

21 Solution: Use the Composite pattern 21

22 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 22

23 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 23

24 Structure of Visitor Pattern 24

25 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 25

26 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. 26

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

28 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 28

29 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 29

30 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. 30

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

32 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. 32

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

34 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 34

35 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 35

36 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 36

37 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. 37

38 The Adapter Pattern 38

39 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 39

40 Adapter has two forms: Class Adapter: Object Adapter: 40

41 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 41

42 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. 42

43 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 43

44 Bridge Pattern UML Diagram 44

45 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 45

46 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. 46

47 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? 47

48 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 48

49 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 49

50 The Decorator Pattern Structure Run time structure 50

51 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 51

52 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 52

53 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 53

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

55 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 55

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

57 Solution 2 Use Decorator pattern Run time structure 57

58 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 58

59 The Prototype pattern structure 59

60 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 runtime; 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 60

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