Satya Puvvada 1

Design Patterns

Satya Puvvada

Satya Puvvada 2

Objectives

Gain an understanding of using design patterns to improve design and implementation

Learn to develop robust, efficient and reusable C++ programs using design patterns

Satya Puvvada 3

Contents – Day 1 Introduction to design patterns Introduction to UML notation Patterns

– Singleton– Factory method– Abstract Factory– Observer– Strategy– Adapter– Visitor

Satya Puvvada 4

Contents – Day 2

Patterns– Builder

– Bridge

– Facade

– Proxy

– Composite

– Chain of responsibility

– Command

Satya Puvvada 5

Contents – Day 3

Patterns– Flyweight

– Memento

– State

– Decorator

– Prototype

– Mediator

Case Study References and conclusions

Satya Puvvada 6

Builder

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Satya Puvvada 7

Builder

Satya Puvvada 8

Builder Structure…

Satya Puvvada 9

Builder

Satya Puvvada 10

Builder Discussion1. Sometimes creational patterns are

complementory: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.

2. Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.

3. Builder is to creation as Strategy is to algorithm.

Satya Puvvada 11

Builder Discussion1. Builder often builds a Composite.

2. Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.

Satya Puvvada 12

Builder Consequences

1. It lets you vary a product's internal representation

2. It isolates code for construction and representation

3. It gives you finer control over the construction process

Satya Puvvada 13

Bridge

Decouple an abstraction from its implementation so that the two can vary independently.

Satya Puvvada 14

Bridge

Every new widget needs two implementations

If you add a third windowing toolkit you need to have 3 implementations per widget

Satya Puvvada 15

Bridge - Motivation

Inheritance binds an implementation to the Inheritance binds an implementation to the abstraction permanently, which makes it difficult abstraction permanently, which makes it difficult to modify, extend and reuse abstractions and to modify, extend and reuse abstractions and implementations independently.implementations independently.

Satya Puvvada 16

Bridge - Motivation (Cont.)

It is inconvenient to extend the window It is inconvenient to extend the window abstraction to cover different kinds of windows or abstraction to cover different kinds of windows or new platform.new platform.

It makes the client-code platform dependent. It makes the client-code platform dependent.

Satya Puvvada 17

Bridge

Satya Puvvada 18

Bridge Structure…

Satya Puvvada 19

Bridge

1. Decoupling interface and implementation

2. Improved extensibility

3. Hiding implementation details from clients

Satya Puvvada 20

Bridge - Applicability

To avoid a permanent binding between an abstraction and its implementation. Specific implementation can be selected at run-time

To independently extend abstraction and implementation by subclassing. Different abstractions can be combined with different implementations.

Changes in the implementation of an abstraction should have no impact on the clients.

Satya Puvvada 21

Bridge - Applicability (Cont.)

• To avoid proliferation of classes as shown in the To avoid proliferation of classes as shown in the Motivation section.Motivation section.

• To share an implementation among multiple To share an implementation among multiple objects. e.g. Handle/Body from Coplien.objects. e.g. Handle/Body from Coplien.

Satya Puvvada 22

Bridge - Consequences

• Decoupling interface and implementation.• Improved extensibility of both abstraction and

implementation class hierarchies.• Hiding implementation detail from client.

Satya Puvvada 23

Bridge - Related Patterns

Similar structure to Adapter but different intent. Abstract Factory pattern can be used with the

Bridge for creating objects.

Satya Puvvada 24

Bridge – Example Image viewer application

designed to view BMP files on Windows operating systems. However, it can easily be extended to view other image formats like JPEG on Windows or view BMP images on other operating systems like OS/2.

example uses two-class hierarchies viz., CImage and CImageImp.

CImage class hierarchy defines the abstraction for the clients and CImageImp class hierarchy provides implementation for the specified abstraction.

Satya Puvvada 25

Bridge – Another Example CImage and its derived classes are responsible

for handling different image formats such as BMP, JPEG, PCX etc., and CImageImp classes are responsible for the representation of the images on different operating systems like Windows, OS/2.

The CImage object provides basic services for loading and showing images and it is configured with a CImageImp object.

Services that are dependent on a particular implementation (like show) are forwarded to CImageImp class (say to PaintImage).

Satya Puvvada 26

Bridge – Another Example

In this way, new image formats can be added to the CImage class hierarchy without affecting the CImageImp and CImageImp can be extended to provide implementation for a new operating system without affecting CImage.

In short, the goal of the Bridge Pattern is achieved, that is, to vary abstraction and implementation independently.

Satya Puvvada 27

Bridge – Another Example

Satya Puvvada 28

Bridge – Another Exampleclass CImage{ // Method declarations public : virtual INT Load( LPCSTR, CRuntimeClass * ) = 0; virtual INT Show( CWnd *, WPARAM );

// Data members protected : CImageImp * m_pImageImp;};

class CBmpImage : public CImage{ // Method declarations public : virtual INT Load( LPCSTR, CRuntimeClass * );};

Satya Puvvada 29

Bridge – Another Exampleclass CImageImp : public CObject{ // Method declarations public : virtual INT InitImageInfo( LPSTR )

= 0; virtual BOOL PaintImage( CWnd *, CRect * )

= 0;

// Attributes public : LPBYTE m_pImage; LONG m_lNormalWidth; LONG m_lNormalHeight;};

Satya Puvvada 30

Bridge – Another Exampleclass CWinImp : public CImageImp{ // Method declarations public : INT InitImageInfo( LPSTR ); BOOL PaintImage( CWnd *, CRect * );

// Attributes protected : BYTE * m_pBmi; CPalette * m_pPalette;};

INT CImage::Show( CWnd * pWnd, WPARAM wParam ){ // Step 1 - Check and delegate this method to m_pImageImp ASSERT( m_pImageImp != NULL ); return m_pImageImp->PaintImage( pWnd, ( CRect * )

wParam );}

Satya Puvvada 31

Bridge – Another ExampleINT CBmpImage::Load( LPCSTR lpszFileName, CRuntimeClass *

pRuntimeClass ){ // Some initialization code before creating image

implementation object … … // Initialize image information, after creating image

implementation object m_pImageImp = ( CImageImp * ) pRuntimeClass->CreateObject(); if( m_pImageImp == NULL ) { … … return FAILURE; } m_pImageImp->InitImageInfo(..); … … return SUCCESS;}

Satya Puvvada 32

Facade - Intent

Provide a unified interface to a set of interfaces Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher level in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use.interface that makes the subsystem easier to use.

Satya Puvvada 33

Facade - Motivation

To reduce complexity of large systems, we need To reduce complexity of large systems, we need to structure it into subsystems. A common goal to structure it into subsystems. A common goal is to reduce dependencies between subsystems. is to reduce dependencies between subsystems. This can be done using Facade, which provides a This can be done using Facade, which provides a single well-defined interface for the more general single well-defined interface for the more general facilities of the subsystem.facilities of the subsystem.

Satya Puvvada 34

Facade- Motivation (cont.)

FacadeFacade

client classesclient classes

subsystem classessubsystem classes

Satya Puvvada 35

Facade -Example

HeapAllocator

MemoryManager

MemorySharingTechnique

MemmoryAllocator

LocalAllocator

PageManagement

Client

PageDirectory

PageTable

Facade

Satya Puvvada 36

Facade - Structure

FacadeFacade

Satya Puvvada 37

Facade - Applicability

• To provide simple interface to a complex To provide simple interface to a complex subsystem, which is useful for most clients.subsystem, which is useful for most clients.

• To reduce the dependencies between the client and To reduce the dependencies between the client and the subsystem, or dependencies between various the subsystem, or dependencies between various subsystems.subsystems.

• To simplify the dependencies between the layers To simplify the dependencies between the layers of a subsystem by making them communicate of a subsystem by making them communicate solely through their facades.solely through their facades.

Satya Puvvada 38

Facade - Consequences• It shields the clients from subsystem components,

thereby making the subsystem easier to use.• It promotes weak coupling between subsystem

and its clients. • Components in a subsystems can change without

affecting the clients.

• Porting of subsystems is easier.

• Simplified interface of the Facade may not be adequate for all clients.

Satya Puvvada 39

Facade - Consequences

• Source code

Satya Puvvada 40

Proxy Pattern Provide a surrogate or placeholder

for another object to control access to it.

Satya Puvvada 41

Proxy Example

Satya Puvvada 42

Proxy Structure

Satya Puvvada 43

Proxy benefits remote proxy can hide the fact that

an object resides in a different address space.

A virtual proxy can perform optimizations such as creating an object on demand.

Both protection proxies and smart references allow additional housekeeping tasks when an object is accessed.

Satya Puvvada 44

Proxy source code Memory overhead Protection proxy

Satya Puvvada 45

Composite Pattern Compose objects into tree structures to

represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Satya Puvvada 46

Composite Example

Satya Puvvada 47

Composite Example

Satya Puvvada 48

Composite Structure

Satya Puvvada 49

Composite

Source code

Satya Puvvada 50

Chain of responsibility

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

Satya Puvvada 51

Satya Puvvada 52

Chain of Responsability

Satya Puvvada 53

Chain of responsability

Satya Puvvada 54

Participants Handler (HelpHandler)

– defines an interface for handling requests. – (optional) implements the successor link.

ConcreteHandler (PrintButton, PrintDialog) – handles requests it is responsible for. – can access its successor. – if the ConcreteHandler can handle the request, it does

so; otherwise it forwards the request to its successor. Client

– initiates the request to a ConcreteHandler object on the chain.

Satya Puvvada 55

Applying Command Pattern… Encapsulate a request as an object,

thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

Satya Puvvada 56

Command Example

Satya Puvvada 57

Command Example

Satya Puvvada 58

Command Structure

Satya Puvvada 59

Command Structure

Satya Puvvada 60

Command Consequences Command decouples the object that

invokes the operation from the one that knows how to perform it.

Commands are first-class objects. They can be manipulated and extended like any other object.

It's easy to add new Commands, because you don't have to change existing classes.

Satya Puvvada 61

Applying Composite on Command