Design Patterns – part I

Design Patterns – part I 1/32 History

Design Patterns:

I are derived from design patterns from architecture

I their name was introduced to the engineering by and Ward Cunningham in 1987

I were made popular by Gang of Four in 1995 through book Design Patterns: Elements of Reusable Object-Oriented Software

Design Patterns – part I 2/32 Solutions of design problems

Design Patterns:

I provide tested solutions of problems

I are not algorithms, because they solve design problems and not computational problems

I are abstract description of connections between classes

Design Patterns – part I 3/32 Describing Design Patterns

Minimal description of Design Patterns:

I pattern name

I intent

I solution

I consequences

Design Patterns – part I 4/32 Classification

Classification of design patterns by their purpose

I creational

I structural

I behavioral

Classification of design patterns by their scope

I class

I object

Design Patterns – part I 5/32 Creational Patterns

I Builder (object)

I Abstract Factory (object)

I Factory Method (class)

I Prototype (object)

I Singleton (object)

Design Patterns – part I 6/32 Structural Patterns

I Adapter (class and object)

I Decorator (object)

I Facada (object)

I Composite (object)

I Bridge (object)

I Proxy (object)

I Flyweight (object)

Design Patterns – part I 7/32 Behavioral Patterns

I Interpreter (class)

I Iterator (object)

I Chain of Responsibility (object)

I Mediator (object)

I Template Method (class)

I Observer (object)

I Visitor (object)

I Memento (object)

I Command (object)

I State (object)

I Strategy (object)

Design Patterns – part I 8/32 with patterns

Steps:

I Specyfying set of design patterns in problem domain. I For obtained set of patterns:

I choose pattern, that prepares context of other patterns, I use this pattern for general design of software, I identify additional patterns, that could appear and add them to analysed problem, I execution of above steps for each design pattern from the set.

I Adding details, defining methods and classes.

Design Patterns – part I 9/32 Strategy

Intent

I Strategy lets the algorithm vary independently from clients that use it.

Motivation

I 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

I many related classes differ only in their behavior I you need different variants of an algorithm I an algorithm uses data that clients shouldn’t know about I a class defines many behaviors, and these appear as multiple conditional statements in its operations.

Design Patterns – part I 10/32 Strategy

Figure: Structure

Design Patterns – part I 11/32 Strategy

Participants

I Strategy

I ConcreteStrategy

I Context

Collaborations

I Strategy and Context interact to implement the chosen algorithm.

I A context forwards requests from its clients to its strategy.

Design Patterns – part I 12/32 Strategy

Consequences

I Families of related algorithms.

I An alternative to subclassing.

I Strategies eliminate conditional statements.

I A choice of implementations.

I Clients must be aware of different Strategies.

I Communication overhead between Strategy and Context.

I Increased number of objects.

Design Patterns – part I 13/32 Strategy

Implementation

template c l a s s Context { v o i d Operation() { theStrategy .DoAlgorithm(); } //... p r i v a t e : AStrategy theStrategy; };

c l a s s MyStrategy { p u b l i c : v o i d DoAlgorithm (); }; Context aContext ;

Design Patterns – part I 14/32 Observer Intent

I Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Motivation

I A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects.

Applicability

I When an abstraction has two aspects, one dependent on the other. I When a change to one object requires changing others. I When an object should be able to notify other objects without making assumptions about who these objects are.

Design Patterns – part I 15/32 Observer

Figure: Structure

Design Patterns – part I 16/32 Observer

Participants

I Subject

I Observer

I ConcreteSubject

I ConcreteObserver

Collaborations

I ConcreteSubject notifies its observers whenever a change occurs that could make its observers’ state inconsistent with its own.

I After being informed of a change in the concrete subject, aConcreteObserver object may query the subject for information.

Design Patterns – part I 17/32 Observer

Consequences

I Abstract coupling between Subject and Observer.

I Support for broadcast communication.

I Unexpected updates.

Design Patterns – part I 18/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 { p u b l i c : v i r t u a l ˜ Observer(); v i r t u a l void Update(Subject ∗ theChangedSubject) = 0; p r o t e c t e d : Observer (); }; c l a s s S u b j e c t { p u b l i c : v i r t u a l ˜Subject (); v i r t u a l void Attach(Observer ∗ ); v i r t u a l void Detach(Observer ∗ ); v i r t u a l void N o t i f y ( ) ; p r o t e c t e d : S u b j e c t ( ) ; p r i v a t e : l i s t o b s e r v e r s ; };

Design Patterns – part I 19/32 Observer Implementation

v o i d Subject ::Attach (Observer ∗ o ) { observers .push back ( o ) ; } v o i d Subject ::Detach (Observer ∗ o ) { observers .remove(o); } v o i d Subject::Notify () { l i s t ::iterator i; f o r ( i= observers.begin(); i!= observers.end(); ++i) { (∗ i)−>Update ( t h i s ); } }

c l a s s ClockTimer : p u b l i c S u b j e c t { p u b l i c : ClockTimer (); v i r t u a l int GetHour ( ) ; v i r t u a l int GetMinute (); v i r t u a l int GetSecond (); v o i d Tick ( ) ; };

v o i d ClockTimer::Tick () { // update internal time−keeping state //... N o t i f y ( ) ; }

Design Patterns – part I 20/32 Composite

Intent

I Compose objects into tree structures to represent part-whole hierarchies.

Motivation

I Graphics applications like drawing editors and schematic capture systems let users build complex diagrams out of simple components.

Applicability

I you want to represent part-whole hierarchies of objects

I you want clients to be able to ignore the difference between compositions of objects and individual objects

Design Patterns – part I 21/32 Composite

Figure: Structure

Design Patterns – part I 22/32 Composite

Participants

I Component

I Leaf

I Komposite

I Client

Collaborations

I Clients use the Component class interface to interact with objects in the composite structure.

Design Patterns – part I 23/32 Composite

Consequences

I defines class hierarchies consisting of primitive objects and composite objects

I makes the client simple

I makes it easier to add new kinds of components

I can make your design overly general

Design Patterns – part I 24/32 Composite Implementation

c l a s s Composite ; c l a s s Component { p u b l i c : //... v i r t u a l Composite∗ GetComposite() { r e t u r n 0 ; } }; c l a s s Composite : p u b l i c Component { p u b l i c : v o i d Add(Component ∗ ); //... v i r t u a l Composite∗ GetComposite() { r e t u r n this ; } }; c l a s s L e a f : p u b l i c Component { //... }; Composite∗ aComposite = new Composite ; L e a f ∗ a L e a f = new L e a f ; Component∗ aComponent ; Composite∗ t e s t ; aComponent = aComposite; i f (test = aComponent−>GetComposite()) { t e s t −>Add ( new L e a f ) ; } aComponent = aLeaf; i f (test = aComponent−>GetComposite()) { t e s t −>Add ( new L e a f ) ; }

Design Patterns – part I 25/32 MVC – Model-View-Controller

Model-View-Controller:

I .

I Includes design patterns. I We can name three groups of objects:

I model – application object, I view – screen representation of model, I controller – defines way how user interface reacts to user input.

Design Patterns – part I 26/32 Model-View-Controller

I Transfers traditional architecture of batch systems:

I input-calculations-output into graphical user interface applications:

I controller-model-view

Design Patterns – part I 27/32 Model-View-Controller

Figure: The organization of MVC

Design Patterns – part I 28/32 Model-View-Controller

Figure: Web application using the MVC pattern

Design Patterns – part I 29/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.

Design Patterns – part I 30/32 Model-View-Controller

Figure: Interaction diagram for MVC

Design Patterns – part I 31/32 Bibliography

I Gamma E. et al.: Design patterns: Elements of Reusable Object-Oriented Software

Design Patterns – part I 32/32