Design Patterns part I. Design Patterns part I 1/32

Transcription

1 Design Patterns part I Design Patterns part I 1/32

2 Design Patterns part I 2/32 History Design Patterns: are derived from design patterns from architecture their name was introduced to the software engineering by Kent Beck and Ward Cunningham in 1987 were made popular by Gang of Four in 1995 through book Design Patterns: Elements of Reusable Object-Oriented Software

3 Design Patterns part I 3/32 Solutions of design problems Design Patterns: provide tested solutions of problems are not algorithms, because they solve design problems and not computational problems are abstract description of connections between classes

4 Design Patterns part I 4/32 Describing Design Patterns Minimal description of Design Patterns: pattern name intent solution consequences

5 Design Patterns part I 5/32 Classification Classification of design patterns by their purpose creational structural behavioral Classification of design patterns by their scope class object

6 Design Patterns part I 6/32 Creational Patterns Builder (object) Abstract Factory (object) Factory Method (class) Prototype (object) Singleton (object)

7 Design Patterns part I 7/32 Structural Patterns Adapter (class and object) Decorator (object) Facada (object) Composite (object) Bridge (object) Proxy (object) Flyweight (object)

8 Design Patterns part I 8/32 Behavioral Patterns Interpreter (class) Iterator (object) Chain of Responsibility (object) Mediator (object) Template Method (class) Observer (object) Visitor (object) Memento (object) Command (object) State (object) Strategy (object)

9 Design Patterns part I 9/32 Software design with patterns Steps: Specyfying set of design patterns in problem domain. For obtained set of patterns: choose pattern, that prepares context of other patterns, use this pattern for general design of software, identify additional patterns, that could appear and add them to analysed problem, execution of above steps for each design pattern from the set. Adding details, defining methods and classes.

10 Strategy Intent Strategy lets the algorithm vary independently from clients that use it. Motivation Many algorithms exist for breaking a stream of text into lines. Hard-wiring all such algorithms into the classes that require them isn t desirable. Applicability many related classes differ only in their behavior you need different variants of an algorithm an algorithm uses data that clients shouldn t know about a class defines many behaviors, and these appear as multiple conditional statements in its operations. Design Patterns part I 10/32

11 Design Patterns part I 11/32 Strategy Figure: Structure

12 Design Patterns part I 12/32 Strategy Participants Strategy ConcreteStrategy Context Collaborations Strategy and Context interact to implement the chosen algorithm. A context forwards requests from its clients to its strategy.

13 Design Patterns part I 13/32 Strategy Consequences Families of related algorithms. An alternative to subclassing. Strategies eliminate conditional statements. A choice of implementations. Clients must be aware of different Strategies. Communication overhead between Strategy and Context. Increased number of objects.

14 Design Patterns part I 14/32 Strategy Implementation template <c l a s s AStrategy> c l a s s Context { v o i d Operation ( ) { t h e S t r a t e g y. DoAlgorithm ( ) ; } //... private : AStrategy thestrategy ; }; c l a s s MyStrategy { public : v o i d DoAlgorithm ( ) ; }; Context<MyStrategy> acontext ;

15 Observer Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Motivation A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects. Applicability When an abstraction has two aspects, one dependent on the other. When a change to one object requires changing others. When an object should be able to notify other objects without making assumptions about who these objects are. Design Patterns part I 15/32

16 Design Patterns part I 16/32 Observer Figure: Structure

17 Design Patterns part I 17/32 Observer Participants Subject Observer ConcreteSubject ConcreteObserver Collaborations ConcreteSubject notifies its observers whenever a change occurs that could make its observers state inconsistent with its own. After being informed of a change in the concrete subject, aconcreteobserver object may query the subject for information.

18 Design Patterns part I 18/32 Observer Consequences Abstract coupling between Subject and Observer. Support for broadcast communication. Unexpected updates.

19 Design Patterns part I 19/32 Observer Implementation c l a s s S u b j e c t ; c l a s s O b s e r v e r { public : v i r t u a l O b s e r v e r ( ) ; v i r t u a l void Update ( Subject thechangedsubject ) = 0 ; protected : O b s e r v e r ( ) ; }; c l a s s S u b j e c t { public : v i r t u a l S u b j e c t ( ) ; v i r t u a l v o i d Attach ( O b s e r v e r ) ; v i r t u a l v o i d Detach ( O b s e r v e r ) ; v i r t u a l v o i d N o t i f y ( ) ; protected : S u b j e c t ( ) ; private : l i s t <O b s e r v e r > o b s e r v e r s ; };

20 Design Patterns part I 20/32 Observer Implementation v o i d Subject : : Attach ( Observer o ) { o b s e r v e r s. p u s h b a c k ( o ) ; } v o i d Subject : : Detach ( Observer o ) { o b s e r v e r s. remove ( o ) ; } v o i d S u b j e c t : : N o t i f y ( ) { l i s t <O b s e r v e r >:: i t e r a t o r i ; f o r ( i= o b s e r v e r s. b e g i n ( ) ; i!= o b s e r v e r s. end ( ) ; ++i ) { ( i) >Update ( t h i s ) ; } } c l a s s ClockTimer : public S u b j e c t { public : ClockTimer ( ) ; v i r t u a l i n t GetHour ( ) ; v i r t u a l i n t GetMinute ( ) ; v i r t u a l i n t GetSecond ( ) ; v o i d Tick ( ) ; }; v o i d ClockTimer : : Tick ( ) { // update i n t e r n a l time k e e p i n g s t a t e //... N o t i f y ( ) ; }

21 Design Patterns part I 21/32 Composite Intent Compose objects into tree structures to represent part-whole hierarchies. Motivation Graphics applications like drawing editors and schematic capture systems let users build complex diagrams out of simple components. Applicability 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

22 Design Patterns part I 22/32 Composite Figure: Structure

23 Design Patterns part I 23/32 Composite Participants Component Leaf Komposite Client Collaborations Clients use the Component class interface to interact with objects in the composite structure.

24 Design Patterns part I 24/32 Composite Consequences defines class hierarchies consisting of primitive objects and composite objects makes the client simple makes it easier to add new kinds of components can make your design overly general

25 Design Patterns part I 25/32 Composite Implementation c l a s s Composite ; c l a s s Component { public : //... v i r t u a l Composite GetComposite ( ) { r e t u r n 0 ; } }; c l a s s Composite : public Component { public : v o i d Add ( Component ) ; //... v i r t u a l Composite GetComposite ( ) { r e t u r n t h i s ; } }; c l a s s L e a f : public Component { //... }; Composite acomposite = new Composite ; Leaf aleaf = new Leaf ; Component acomponent ; Composite t e s t ; acomponent = acomposite ; i f ( t e s t = acomponent >GetComposite ( ) ) { test >Add (new Leaf ) ; } acomponent = aleaf ; i f ( t e s t = acomponent >GetComposite ( ) ) { test >Add (new Leaf ) ; }

26 Design Patterns part I 26/32 MVC Model-View-Controller Model-View-Controller: Architectural pattern. Includes design patterns. We can name three groups of objects: model application object, view screen representation of model, controller defines way how user interface reacts to user input.

27 Design Patterns part I 27/32 Model-View-Controller Transfers traditional architecture of batch systems: input-calculations-output into graphical user interface applications: controller-model-view

28 Design Patterns part I 28/32 Model-View-Controller Figure: The organization of MVC

29 Design Patterns part I 29/32 Model-View-Controller Figure: Web application using the MVC pattern

30 Design Patterns part I 30/32 Model-View-Controller Scenario: User provides input into window: 1. Controller instructs model to store the text provided by the user. 2. Model notifies all views about change. 3. All views redraw itself. 4. During redraw all views ask model about the text provided by the user.

31 Design Patterns part I 31/32 Model-View-Controller Figure: Interaction diagram for MVC

32 Design Patterns part I 32/32 Bibliography Gamma E. et al.: Design patterns: Elements of Reusable Object-Oriented Software