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 Case Study References and conclusions
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 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

11. 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

12. 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

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 abstraction permanently, which makes it difficult to modify, extend and reuse abstractions and implementations independently.
Satya Puvvada

16. 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

17. Bridge
Satya Puvvada

18. Bridge Structure…
Satya Puvvada

19. Bridge Decoupling interface and implementation Improved extensibility
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 Motivation section.
To share an implementation among multiple 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 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

29. 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

30. 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

31. 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

32. 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

33. 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

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

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

36. Facade - Structure
Facade
Satya Puvvada

37. 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

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
Satya Puvvada