Traditional Design Patterns -- I

Transcription

1 Traditional Design Patterns -- I These slides are mainly based on: Tutorial slides by John Vlissides, see Text by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Diagrams 1995 by Addison-Wesley Publishing Company Note: Compared to the original tutorial by John Vlissides, the diagram notation have been upgraded from OMT to UML and some text has been updated 1

2 Overview Motivation and Concept Observer Example: WYSIWYG Editor Composite Strategy Decorator Abstract Factory 2

3 Analysis vs. Design Analysis Domain level - modeling real world objects Many domain objects will not make into the design Domain structures usually make poor design structures Design Assigning responsibilities to object Taking illities (maintainability, reusability, etc.) and portability into account Devising mechanisms But how to get to the design objects and mechanisms? 3

4 Motivation and Concept 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 4

5 Motivation and Concept OO systems exploit recurring design structures that promote Abstraction Flexibility Modularity Elegance Therein lies valuable design knowledge Problem: capturing, communicating, and applying this knowledge 5

6 What Is a Design Pattern? A design pattern Is a common solution to a recurring problem in design Abstracts a recurring design structure Comprises class and/or object Dependencies Structures Interactions Conventions Names & specifies the design structure explicitly Distils design experience 6

7 What Is a Design Pattern? A design pattern has 4 basic parts: 1. Name 2. Problem 3. Solution 4. Consequences and trade-offs of application Language- and implementation-independent A micro-architecture Adjunct to existing methodologies (Unified, OMT, etc.) No mechanical application The solution needs to be translated into concrete terms in the application context by the developer 7

8 Example: Observer 8

9 Goals Codify good design Distil and disseminate experience Aid to novices and experts alike Abstract how to think about design Give design structures explicit names Common vocabulary Reduced complexity Greater expressiveness Capture and preserve design information Articulate design decisions succinctly Improve documentation Facilitate restructuring/refactoring Patterns are interrelated Additional flexibility 9

10 Design Pattern Catalogues GoF ( the gang of four ) catalogue Design Patterns: Elements of Reusable Object- Oriented Software, Gamma, Helm, Johnson, Vlissides, Addison-Wesley, 1995 POSA catalogue Pattern-Oriented Software Architecture, Buschmann, et al.; Wiley,

11 Classification of GoF Design Pattern Creational Structural Behavioral Factory Method Adapter Interpreter Abstract Factory Bridge Template Method Builder Prototype Singleton Composite Decorator Flyweight Facade Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 11

12 Design Pattern Template (First Half ) Name (and classification) Intent Short description of pattern and its purpose Also known as Other names that people have for the pattern Motivation Motivating scenario demonstrating pattern's use Applicability Circumstances in which pattern applies Structure Graphical representation of the pattern GoF used OMT and interaction diagrams (a precursor to UML) Participants Participating classes and/or objects and their responsibilities... 12

13 Design Pattern Template (Second Half )... Collaborations How participants cooperate to carry out their responsibilities Consequences The results of application, benefits, liabilities Implementation Implementation pitfalls, hints, or techniques, plus any language-dependent issues Sample code Sample implementations in C++, Java, C#, Smalltalk, etc. Known uses Examples drawn from existing systems Related patterns Discussion of other patterns that relate to this one 13

14 Observer (Behavioral) Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically Applicability When an abstraction has two aspects, one dependent on the other When a change to one object requires changing others, and you don't know how many objects need to be changed When an object should notify other objects without making assumptions about who these objects are 14

15 Observer (Cont'd) Structure 15

16 Observer (Cont'd) Consequences + Modularity: subject and observers may vary independently + Extensibility: can define and add any number of observers + Customizability: different observers provide different views of subject Unexpected updates: observers don't know about each other Update overhead: might need hints Implementation Subject-observer mapping Dangling references Avoiding observer-specific update protocols: the push and push/ pull models Registering modifications of interest explicitly 16

17 Observer (Cont'd) Known uses Smalltalk model-view-controller (MVC) Interviews (subjects and views) Andrew (data objects and views) Benefits Design reuse Uniform design vocabulary Enhance understanding, restructuring Basis for automation 17

18 Observer (Cont'd) Structure 18

19 Schematic Observer Example Observers Subject 19

20 Observer - Sample Code class Subject { public: virtual ~Subject(); virtual void Attach(Observer*); virtual void Detach(Observer*); virtual void Notify(); protected: Subject(); private: List<Observer*> *_observers; ; void Subject::Attach (Observer* o) { _observers->insert(_observers->end(), o); void Subject::Detach (Observer* o) { _observers->remove(o); void Subject::Notify () { ListIterator<Observer*>i(_observers); for (i.first();!i.isdone(); i.next()) { i.currentitem()->update(this); class Observer { public: virtual ~Observer(); virtual void Update(Subject* thechangesubject) = 0; protected: Observer(); ; class ClockTimer : public Subject { public: ClockTimer(); virtual int GetHour(); virtual int GetMinute(); virtual int GetSecond(); void Tick(); ; void ClockTimer::Tick() { // update internal time-keeping state //... Notify(); 20

21 Observer Sample Code class DigitalClock: public Observer { public: DigitalClock(ClockTimer *); ~DigitalClock(); void Update(Subject *); void Draw(); private: ClockTimer *_subject; ; DigitalClock::DigitalClock (ClockTimer *s) { _subject = s; _subject->attach(this); DigitalClock::~DigitalClock () { _subject->detach(this); void DigitalClock::Update (Subject *thechangedsubject) { if(thechangedsubject == _subject) draw(); void DigitalClock::Draw () { int hour = _subject->gethour(); int minute = _subject->getminute(); int second = _subject->getsecond(); // draw operation class AnalogClock: public Observer { public: AnalogClock(ClockTimer *); ~AnalogClock(); void Update(Subject *); void Draw(); private: ClockTimer *_subject; ; int main(void) { ClockTimer *timer = new ClockTimer; AnalogClock *analogclock = new AnalogClock(timer); DigitalClock *digitalclock = new DigitalClock(timer); timer->tick(); return 0; 21

22 Overview Motivation and Concept Observer Example: WYSIWYG Editor Composite Strategy Decorator Abstract Factory 22

23 Example: WYSIWYG Editor 7 design problems: Document structure Formatting Embellishment Multiple look & feels Multiple window systems User operations Spelling checking & hyphenation 23

24 Overview Motivation and Concept Observer Example: WYSIWYG Editor Composite - Document Structure Strategy - Formatting Decorator - Embellishment Abstract Factory - Multiple Look&Feels 24

25 Document Structure Goals: Present document's visual aspects Drawing, hit detection, alignment Support physical structure (e.g., lines, columns) Constraints: Treat text and graphics uniformly No distinction between one and many 25

26 Document Structure Solution: Recursive composition 26

27 Document Structure (Cont'd) Object structure 27

28 Document Structure (Cont'd) Glyph: base class for composable graphical objects Basic interface: Task appearance hit detection structure Operations void draw(window) boolean intersects(coord, Coord) insert(glyph) void remove(glyph) Glyph child(int) Glyph parent() Subclasses: Character, Image, Space, Row, Column 28

29 Document Structure (cont'd) 29

30 Schematic Observer Example Observers Subject 30

31 Composite (Structural) Intent Treat individual objects and multiple, recursivelycomposed objects uniformly Applicability Objects must be composed recursively, And there should be no distinction between individual and composed elements, And objects in the structure can be treated uniformly Part-Whole hierarchy of objects. Constant handling of objects as groups or individuals 31

32 Composite (Cont'd) Structure 32

33 Composite (Cont'd) Consequences + Uniformity: treat components the same regardless of complexity + Extensibility: new Component subclasses work wherever old ones do Overhead: might need prohibitive numbers of objects Implementation Do Components know their parents? Uniform interface for both leaves and composites? Don't allocate storage for children in Component base class Responsibility for deleting children 33

34 Composite (Cont'd) Known Uses ET++ VObjects InterViews Glyphs, Styles Unidraw Components, MacroCommands 34

35 Composite - Example 35

36 Composite Sample Code Currency CompositeEquipment::NetPrice() { Iterator<Equipment*>* i = getiterator(); Currency total = 0; for (i->first();!i->isdone(); i->next()) total += i->currentitem()->netprice(); delete i; return total; // and in the client code (e.g. in 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("16Mbs Token Ring") ); chassis->add( bus ); chassis->add( new FloppyDisk("3.5 floppy") ); cout << chassis->netprice() << endl; 36

37 Question? What does the pattern let you vary? 37

38 Overview Motivation and Concept Observer Example: WYSIWYG Editor Composite - Document Structure Strategy - Formatting Decorator - Embellishment Abstract Factory - Multiple Look&Feels 38

39 Formatting Goals: Automatic linebreaking, justification Constraints: Support multiple linebreaking algorithms Don't mix up with document structure 39

40 Formatting (Cont'd) Solution: encapsulate linebreaking strategy Compositor Base class abstracts linebreaking algorithm Subclasses for specialized algorithms, e.g., SimpleCompositor, TeXCompositor Composition Composite glyph Supplied a compositor and leaf glyphs Creates row-column structure as directed by compositor 40

41 Formatting (Cont'd) 41

42 Strategy (Behavioral) Intent Define a family of algorithms, encapsulate each one, and make them interchangeable to let clients and algorithms vary independently Applicability When an object should be configurable with one of several algorithms, and all algorithms can be encapsulated, and one interface covers all encapsulations 42

43 Strategy (Cont'd) Structure 43

44 Strategy (Cont'd) Consequences + Greater flexibility, reuse + Can change algorithms dynamically Strategy creation & communication overhead Inflexible strategy interface Implementation Exchanging information between a strategy and its context Static strategy selection via templates Known uses Interviews text formatting RTL register allocation & scheduling strategies Et++SwapsManager calculation engines 44

45 Strategy - Example 45

46 Strategy Sample Code class ConcreteContext : public Context{ public: ConcreteContext(); ConcreteContext(Strategy<class T> *); ConcreteContext(const ConcreteContext &); int array[10]; Strategy *thisstratergy; Boolean aggregation; void execute(); void attachstrategy(strategy *s); ; template <class T> class Print : public Strategy<T>{ public: virtual void doalgorithm(t* const); Print<class T> *clone(); ; template <class T> class DecreasePrint : public Strategy<T>{ public: virtual void doalgorithm(t* const cont); void quicksortd(int array[], int l, int r); DecreasePrint<class T> *clone(); int array[10]; ; template <class T> void IncreasePrint<T>::doAlgorithm( T* const cont) { for (int i=0; i<10; i++) array[i] = cont->array[i]; quicksorti(array, 0, 9); printf("increasing ORDER\n"); for (int i=0; i<10; i++) ::printf("element no %d = %d\n", i, array[i]); 46

47 Strategy Sample Code template <class T> void DecreasePrint<T>::doAlgorithm(T* const cont){ for (int i=0; i<10; i++) array[i] = cont->array[i]; quicksortd(array, 0, 9); ::printf("decreasing ORDER\n"); for (int i=0; i<10; i++) ::printf("element no %d = %d\n", i, array[i]); void Context::execute(){ if(thisstrategy){ thisstrategy->doalgorithm((t *)this); else { ::printf("error: there is no strategy attached to the context\n"); ::printf("an exeception has been thrown\n"); throw "Error: there is no stategy attach to the context"; void Context::attachStrategy(Strategy<class T> * anotherstrategy){ if (aggregation) delete thisstrategy; thisstrategy = anotherstrategy; 47

48 Strategy - Sample Code Context::Context(const Context &t) { if(t.aggregation){ thisstrategy = t.thisstrategy->clone(); else aggregation = true; { thisstrategy = t.thisstrategy; aggregation = false; 48

49 Strategy Sample Code main(int argc, char **argv){ ConcreteContext * context1 = new ConcreteContext(); context1->attachstrategy((strategy<t> *)(new Print<ConcreteContext>())); context1->execute(); ::printf("*****************\n"); ConcreteContext * context2 = new ConcreteContext(*context1); // Copy constructor context1->attachstrategy((strategy<t> *)(new IncreasePrint<ConcreteContext>())); context1->execute(); ::printf("*****************\n"); context1->removestrategy(); context1->attachstrategy((strategy<t> *)(new DecreasePrint<ConcreteContext>())); context1->execute(); context1->removestrategy(); delete context1; ::printf("*****context2******\n"); context2->execute(); context2->removestrategy(); delete context2; :: printf("\n Testing Aggregation \n\n"); context1 = new ConcreteContext( (Strategy<T> *)(new IncreasePrint<ConcreteContext>())); context1->execute(); ::printf("*****************\n"); context2 = new ConcreteContext(*context1); delete context1; context2->execute(); delete context2; 49

50 Overview Motivation and Concept Observer Example: WYSIWYG Editor Composite - Document Structure Strategy - Formatting Decorator - Embellishment Abstract Factory - Multiple Look&Feels 50

51 Embellishment Goals: Add a frame around text composition Add scrolling capability Constraints: Embellishments should be reusable without subclassing Should go unnoticed by clients 51

52 Embellishment (Cont'd) Solution: Transparent enclosure MonoGlyph Base class for glyphs having one child Operations on MonoGlyph pass through to child MonoGlyph subclasses: Frame: adds a border of specified width Scroller: scrolls/clips child, adds scrollbars 52

53 Embellishment (Cont'd) Structure 53

54 Embellishment (Cont'd) New object structure 54

55 Decorator (Structural) Intent Augment objects with new responsibilities Applicability When extension by subclassing is impractical For responsibilities that can be withdrawn 55

56 Decorator Diagram Structure 56

57 Decorator - Diagram 57

58 Decorator Overview A Decorator, also known as a Wrapper, is an object that has an interface identical to an object that it contains. Any calls that the decorator gets, it relays to the object that it contains, and adds its own functionality along the way, either before or after the call. Therefore, the Decorator Pattern is used for adding additional functionality to a particular object as opposed to a class of objects. It is easy to add functionality to an entire class of objects by subclassing an object, but it is impossible to extend a single object this way. With the Decorator Pattern, you can add functionality to a single object and leave others like it unmodified. 58

59 Decorator Comments The Decorator pattern gives you a lot of flexibility, since you can change what the decorator does at runtime, as opposed to having the change be static and determined at compile time by subclassing. Since a Decorator complies with the interface that the object that it contains, the Decorator is indistinguishable from the object that it contains. That is, a Decorator is a concrete instance of the abstract class, and thus is indistinguishable from any other concrete instance, including other decorators. This can be used to great advantage, as you can recursively nest decorators without any other objects being able to tell the difference, allowing a near infinite amount of customization. 59

60 Decorator (Cont'd) Consequences + Responsibilities can be added/removed at run-time + Avoids subclass explosion + Recursive nesting allows multiple responsibilities Interface occlusion Identity crisis Implementation Interface conformance Use a lightweight, abstract base class for Decorator Heavyweight base classes make Strategy more attractive 60

61 Decorator (Cont'd) Known Uses Embellishment objects from most OO-GUI toolkits ParcPlace PassivityWrapper InterViews DebuggingGlyph 61

62 Decorator Example package dpj.structural.decorator; class VisualComponent { public VisualComponent () { public void draw () { public void resize () { // class VisualComponent class TextView extends VisualComponent { public TextView () { public void draw () { public void resize () { // class TextView class Window { public Window () { public void setcontents (VisualComponent vc) { contents = vc; VisualComponent contents; // class Window class Decorator extends VisualComponent { public Decorator (VisualComponent vc) { public void draw () { component.draw (); public void resize () { component.resize (); private VisualComponent component; // class Decorator 62

63 Decorator Example class BorderDecorator extends Decorator { public BorderDecorator (VisualComponent vc, int borderwidth) { super (vc); width = borderwidth; public void draw () { super.draw (); drawborder (width); /* Class internals */ private void drawborder (int width) { private int width; // class BorderDecorator class ScrollDecorator extends Decorator { public ScrollDecorator (VisualComponent vc, int scrsize) { super (vc); scrollsize = scrsize; public void draw () { scroll(); super.draw (); /* Class internals */ private void scroll () { private int scrollsize; // class ScrollDecorator 63

64 Decorator Example class Client { public static void main (String[] args ) { // main Window window = new Window (); TextView textview = new TextView (); window.setcontents (new BorderDecorator ( new ScrollDecorator (textview, 500), 1 ) ); // class Client 64

65 Decorator Example 65

66 Decorator Example class Book extends LibItem{ String author; intnocopies; intonshelf; String title; public Book(String t, String a, int c){ title = t; nocopies= c; author = a; onshelf= c; public String gettitle() { return title; public int getcopies() { return nocopies; public int copiesonshelf() { return onshelf; public void deccopiesonshelf() { onshelf--; public void inccopiesonshelf() { onshelf++; public String getauthor() { return author; public void borrowitem(string borrower) { System.out.println("borrow in Book"); public void returnitem(string borrower) { public void reserve(string reserver) { /* End class Book */ 66

67 Decorator Example abstract class Decorator extends LibItem{ LibItem item; public Decorator(LibItem li) { item = li; public String gettitle() { return item.gettitle(); // Following methods are // similarly implemented public String getauthor() {... public intgetcopies() {... public intcopiesonshelf() {... public void deccopiesonshelf() { item.deccopiesonshelf(); // and similarly... public void inccopiesonshelf() {... 67

68 Decorator Example 68

69 Decorator Example - (client) // Non borrowable, non reservablebook LibItem b1 = new Book("A", "B", 1); // Borrowablevideo LibItem v1 = new BorrowableDec(new Video("V", 3)); // borrow unborrowableitem -copies should stay 1 b1.borrowitem("bob"); System.out.println("Copiesof book = " +b1.copiesonshelf()); // borrow video -copies decremented to 2 v1.borrowitem("fred"); System.out.println("Copiesof video = " +v1.copiesonshelf()); //make book borrowableand borrow it -copies = 0 LibItem b2 = new BorrowableDec(b1); b2.borrowitem("bob"); System.out.println("Copiesof book = " +b2.copiesonshelf()); // make book reservable LibItem b3 = new ReservableDec(b2); b3.reserve("alice"); b3.returnitem("bob"); // book returned -back to 1 copy System.out.println("Copiesof book = " +b3.copiesonshelf()); // Not reserved for Jane -still 1 copy b3.borrowitem("jane"); System.out.println("Copiesof book = " +b3.copiesonshelf()); // Okay Alice can borrow -down to 0 b3.borrowitem("alice"); System.out.println("Copiesof book = " +b3.copiesonshelf()); 69

70 Decorator Diagram Structure 70

71 Overview Motivation and Concept Observer Example: WYSIWYG Editor Composite - Document Structure Strategy - Formatting Decorator - Embellishment Abstract Factory - Multiple Look&Feels 71

72 Multiple Look & Feels Goals: Support multiple look and feel standards Generic, Motif, PM, Macintosh, Windows,... Extensible for future standards Constraints: Don't recode existing widgets or clients Switch look and feel without recompiling 72

73 Multiple Look & Feels (Cont'd) Solution: Abstract the process of creating objects Instead of use Scrollbar sb = new MotifScrollbar(); Scrollbar sb = factory.createscrollbar(); where factory is an instance of MotifFactory 73

74 Multiple Look & Feels (Cont'd) Factory interface Defines manufacturing interface Subclasses produce specific products Subclass instance chosen at run-time interface Factory { Scrollbar createscrollbar(); Menu createmenu();... 74

75 Multiple Look & Feels (Cont'd) Structure «instantiate» «instantiate» 75

76 Abstract Factory (Creational) Intent Create families of related objects without specifying class names Applicability When clients cannot anticipate groups of classes to instantiate 76

77 Abstract Factory (Cont'd) Structure «instantiate» «instantiate» «instantiate» «instantiate» 77

78 Abstract Factory - Example public class MazeFactory { public MazeFactory() {... public Maze makemaze(){ return new Maze(); public Room makeroom(int n) { return new Room(n); public Wall makewall() { return new Wall(); public Door makedoor(room r1, Room r2) { return new Door(r1, r2); ; public class MazeGame { //... public Maze createmaze (MazeFactory factory) { Maze amaze = factory.makemaze(); Room r1 = factory.makeroom(1); Room r2 = factory.makeroom(2); Door thedoor = factory.makedoor(r1, r2); amaze.addroom(r1); amaze.addroom(r2); r1.setside(mapsite.north, factory.makewall()); r1.setside(mapsite.east, thedoor); r1.setside(mapsite.south, factory.makewall()); r1.setside(mapsite.west, factory.makewall()); r2.setside(mapsite.north, factory.makewall()); r2.setside(mapsite.east, factory.makewall()); r2.setside(mapsite.south, factory.makewall(); r2.setside(mapsite.west, thedoor); return amaze; 78

79 Abstract Factory - Example public class EnchantedMazeFactory extends MazeFactory { public EnchantedMazeFactory() {... public Room makeroom(int n) { return new EnchantedRoom(n, new Spell()); public Door makedoor(room r1, Room r2) { return new DoorNeedingSpell(r1, r2); public class BombedMazeFactory extends MazeFactory { public BombedMazeFactory() {... public Wall makewall(){ return new BombedWall(); public Room makeroom(int n){ return new RoomWithABomb(n); 79

80 Abstract Factory - Client MazeGame game; // The instance of a game.. Maze amaze; // A reference to a maze. switch(choice) { case ENCHANTED: { EnchantedMazeFactory factory = new EnchantedMazeFactory(); amaze = game.createmaze(factory); break; case BOMBED: { BombedMazeFactory factory = new BombedMazeFactory(); amaze = game.createmaze(factory); break; 80

81 Example Class Diagram 81

82 Abstract Factory (Cont'd) Consequences + Flexibility: removes type dependencies from clients + Abstraction: hides product's composition Hard to extend factory interface to create new products Implementation Parameterization as a way of controlling interface size Configuration with Prototypes Known Uses InterViews Kits ET++ WindowSystem 82

83 Overview Motivation and Concept Observer Example: WYSIWYG Editor Composite - Document Structure Strategy - Formatting Decorator - Embellishment Abstract Factory - Multiple Look&Feels 83