1 / 61

Design Patterns

Design Patterns. 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. Contents – Day 1. Introduction to design patterns Introduction to UML notation

rolf
Télécharger la présentation

Design Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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 { // Method declarations public : 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 public : 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 PageDirectory PageManagement MemmoryAllocator 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

More Related