1 / 18

Design Pattern Space

Design Pattern Space. Creational Structural Behavioural. Class. Interpreter Template method. Factory Method. Adaptor (Class). Abstract Factory Builder Prototype Singleton. Adaptor (Object) Bridge Composite Decorator Flyweight Façade Proxy. Chain of Responsibility Command

brian
Download Presentation

Design Pattern Space

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 Pattern Space Creational Structural Behavioural Class Interpreter Template method Factory Method Adaptor (Class) Abstract Factory Builder Prototype Singleton Adaptor (Object) Bridge Composite Decorator Flyweight Façade Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor Scope Object Design Patterns

  2. The Proxy Pattern • A Structural Pattern. • Provides surrogate for another object, controls access to real target object. • Separates interface from implementation. • Real target may not always be instantiated directly due to performance, location or access restrictions. • One of the simpler patterns. Design Patterns

  3. Subject {abstract} Request() Client Proxy RealSubject refers to ->Request() Request() Request() Design Patterns

  4. Notes on Diagram • Three Classes: Subject, RealSubject, and Proxy. • Client always operates with interface defined in {abstract} class Subject. • Interface to Subject implemented in both RealSubject, and Proxy. • Proxy delegates any calls to RealSubject. • Client always uses Proxy. Design Patterns

  5. Example Application • Document editor with embedded Objects, say images, expensive to create. • Opening document should be fast, not so if all images must be loaded. • No need to load all as not all will be viewable in Window. • Lets create images on demand ! Design Patterns

  6. Graphic Draw() GetExtent() Store() Load() Document Editor Image imageImp extent Draw() GetExtent() Store() Load() ImageProxy fileName extent Draw() GetExtent() Store() Load() if(image= =0) image=LoadImage(fileName); image->Draw(); image if(image= =0) return(extent); else return(image->GetExtent(); Design Patterns

  7. Implementing in C++ class Image; extern Image* LoadAnImageFile(const char*); class ImagePtr{ public: ImagePtr(const char* imageFile); virtual ~ImagePtr(); virtual Image* operator->(); virtual Image& operator*(); private: Image* LoadImage(); private: Image* _image const char* _imageFile }; ImagePtr::ImagePtr(const char* theImageFile){ _imageFile = theImageFile; _image = 0; } Image* ImagePtr::LoadImage(){ if(_image = = 0) _image = LoadAnImageFile(_imageFile); return(_image); } Design Patterns

  8. /*overloaded -> and * use LoadImage to return _image to callers and loading it if necessary */ Image* ImagePtr:: operator->(){ return LoadImage(); } Image& ImagePtr:: operator*(){ return *LoadImage(); } Design Patterns

  9. /* now using this code, we can use Image operations through ImagePtr objects without making the operations part of the ImagePtr interface. //constructor first, set up a pointer to image, a proxy ImagePtr image = ImagePtr(“theImageFileName”); //image is of Image class image->Draw(Point(50, 100)); //through the proxy /* here the overloaded operator -> is used to return the address of the real object and invoke the LoadImage() function which in turn calls the LoadAnImageFile() function as illustrated thus ….. */ //(image.operator->( ))->Draw(Point(50, 100)); Design Patterns

  10. Notes on Implementation • Proxy acts like a pointer, yet not declared as a pointer to an image. So cannot use exactly as a pointer. • If proxy needs to know which operation is called, then overloading member access operators in this way will not work. • In this case we must manually implement each proxy operation and forward request as we did with LoadImage(). Design Patterns

  11. Applicability of Pattern • Remote Proxy: provide local representative for object in different address space, may re-code request. • Virtual Proxy: creates expensive objects on demand, like in example, may also cache. • Protection Proxy: control access to original object, useful when access rights differ. Design Patterns

  12. Applicability of Pattern (cont.) • Smart Reference: replace bare pointer, include functionality like • counting references, deleting when no longer referenced (smart pointers). • load persistent object into memory when first referenced • control locking of object before access. Design Patterns

  13. Patterns inUML • Collaboration Diagrams (interaction) document Design Patterns in UML. • Context (Object Diagram) and interaction are described. aClient: Client aRealSubject: Subject aProxy: Proxy Object Diagram describes context aRealSubject: Subject {new} 1.1:Request() 1:Request() aClient: Client aProxy: Proxy Collaboration Diagram describes interaction Design Patterns

  14. aRealSubject: Subject aClient: Client aProxy: Proxy Sequence Diagram also describes interaction Design Patterns

  15. Design Patterns:UML Parameterised Collaborations Sales Sales Interface proxy subject Proxy The Classes are the participants in the Parameterised Collaboration. Sales Statistics realsubject Design Patterns

  16. Roles in the Collaboration • In the Proxy pattern • Sales Interface plays the roleof subject. • Sales Statistics plays the role of realsubject. • Sales plays the role of proxy. • Dependency annotated by dashed arrows. Design Patterns

  17. Sales Interface {abstract} Client Sales Statistics Sum() Sales Sum() refersTo refersTo->Sum() Design Patterns

  18. C++ Node Interface #ifndef _NODE_H //this is “Node.h” #define _NODE_H class Tree; //forward class Node{ //describe vertices friend class Tree; protected: Node(void):use_(1){} virtual void print(ostream&)const=0; //pure virtual virtual ~Node(void); //important to make virtual private: int use_; //reference counter }; #endif Design Patterns

More Related