Design Patterns Satya Puvvada Satya Puvvada

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

Contents – Day 1 Introduction to design patterns Introduction to UML notation Patterns Singleton Factory method Abstract Factory Observer Strategy Adapter Visitor Satya Puvvada

Contents – Day 2 Patterns Builder Bridge Facade Proxy Composite Chain of responsibility Command Satya Puvvada

Contents – Day 3 Patterns Case Study References and conclusions Flyweight Memento State Decorator Prototype Mediator Case Study References and conclusions Satya Puvvada

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

Builder Satya Puvvada

Builder Structure… Satya Puvvada

Builder Satya Puvvada

Builder Discussion 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. 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. Builder is to creation as Strategy is to algorithm. Satya Puvvada

Builder Discussion Builder often builds a Composite. 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

Builder Consequences It lets you vary a product's internal representation It isolates code for construction and representation It gives you finer control over the construction process Satya Puvvada

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

Bridge Every new widget needs two implementations If you add a third windowing toolkit you need to have 3 implementations per widget Satya Puvvada

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

Bridge - Motivation (Cont.) It is inconvenient to extend the window abstraction to cover different kinds of windows or new platform. It makes the client-code platform dependent. Satya Puvvada

Bridge Satya Puvvada

Bridge Structure… Satya Puvvada

Bridge Decoupling interface and implementation Improved extensibility Hiding implementation details from clients Satya Puvvada

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

Bridge - Applicability (Cont.) To avoid proliferation of classes as shown in the Motivation section. To share an implementation among multiple objects. e.g. Handle/Body from Coplien. Satya Puvvada

Bridge - Consequences Decoupling interface and implementation. Improved extensibility of both abstraction and implementation class hierarchies. Hiding implementation detail from client. Satya Puvvada

Bridge - Related Patterns Similar structure to Adapter but different intent. Abstract Factory pattern can be used with the Bridge for creating objects. Satya Puvvada

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

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

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

Bridge – Another Example Satya Puvvada

Bridge – Another Example class 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 virtual INT Load( LPCSTR, CRuntimeClass * ); Satya Puvvada

Bridge – Another Example class CImageImp : public CObject { // Method declarations public : virtual INT InitImageInfo( LPSTR ) = 0; virtual BOOL PaintImage( CWnd *, CRect * ) = 0; // Attributes LPBYTE m_pImage; LONG m_lNormalWidth; LONG m_lNormalHeight; }; Satya Puvvada

Bridge – Another Example class 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

Bridge – Another Example INT 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

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

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

Facade- Motivation (cont.) client classes Facade subsystem classes Satya Puvvada

Facade -Example Facade Client MemoryManager MemmoryAllocator PageManagement PageDirectory PageTable HeapAllocator LocalAllocator MemorySharingTechnique Satya Puvvada

Facade - Structure Facade Satya Puvvada

Facade - Applicability To provide simple interface to a complex subsystem, which is useful for most clients. To reduce the dependencies between the client and the subsystem, or dependencies between various subsystems. To simplify the dependencies between the layers of a subsystem by making them communicate solely through their facades. Satya Puvvada

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

Facade - Consequences Source code Satya Puvvada

Proxy Pattern Provide a surrogate or placeholder for another object to control access to it. Satya Puvvada

Proxy Example Satya Puvvada

Proxy Structure Satya Puvvada

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

Proxy source code Memory overhead Protection proxy Satya Puvvada

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

Composite Example Satya Puvvada

Composite Example Satya Puvvada

Composite Structure Satya Puvvada

Composite Source code Satya Puvvada

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

Satya Puvvada

Chain of Responsability Satya Puvvada

Chain of responsability Satya Puvvada

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

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

Command Example Satya Puvvada

Command Example Satya Puvvada

Command Structure Satya Puvvada

Command Structure Satya Puvvada

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

Applying Composite on Command Satya Puvvada