1 / 32

Design Patterns

Design Patterns. Design pattern. Design pattern is a solution to a problem, which occurs over and over again. Pattern elements: Name – a handle we use to describe a pattern in a word or two Problem – describes when to apply a pattern

Download Presentation

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

  2. Design pattern • Design pattern is a solution to a problem, which occurs over and over again. Pattern elements: • Name – a handle we use to describe a pattern in a word or two • Problem – describes when to apply a pattern • Solution – describes a set of design elements which solve a problem • Consequences – benefits, disadvantages, constraints

  3. Pattern types E. Gamma classification: • Structural patterns – solve objects composition problems • Abstract Server, Adapter, Bridge, Proxy ... • Creational patterns – abstract the instantiation process and make a system independent on how objects are created • Abstract Factory, Factory Method, Singleton ... • Behavioral patterns - algorithms and the assignment of responsibilities between objects • Chain of Responsibility, Command, Iterator, Observer, State, Strategy ...

  4. Abstract Server: Problem Problem: - Button is not reusable in a context not involving a light

  5. Abstract Server: Solution Solution: break dependency between Button and Light by inserting an interface

  6. Abstract Server: Pattern • Benefits: • decouples clients from their servers • servers can be changed without affecting clients • eliminates DIP violation

  7. Adapter: Problem • Problem: • Light already exists and can’t inherit from Device • Device might have messages activate/deactivate

  8. Adapter: Solution - use an adapter to convert one interface to another

  9. Adapter: Pattern Also known as: Wrapper Benefits: - breaks dependency between client and server when server exists - allows different servers to be swapped in and out

  10. Adapter: Pattern A variation, which allows server methods to be redefined

  11. Abstract Client: Problem • Problem: • Server needs to send callback message to client • GUI Button is not a reusable class • Callback method makes Device unreusable

  12. Abstract Client: Solution • Server provides interface for client to use

  13. Abstract Client: Pattern • Q: What package should contain AbstractClient class ? • A: Server’s package

  14. Adapted Client Problem: GUI library components (JButton) do not implement StateListener Solution: use Adapter pattern along with Abstract Client

  15. Singleton: Problem • Problem: • How many database objects do we need in a simple program? • Would it be a bad thing is someone mistakenly created more? • Solution: • prevent programmers from making objects. • Make constructors private or protected. • make the class responsible for making the one and only object

  16. Singleton: Solution class CompanyDb { private: static CompanyDb* db; CompanyDb(); ~CompanyDb(); public: static CompanyDb* Instance() { if( 0 == db ) return db = new CompanyDb(); return db; } Employee* getEmployee( const char* name ); }; • Use singleton when: • there must be exactly one instance of a class • it must be accessible to clients from anywhere inside the program: CompanyDb::Instance()->getEmployee(“Leha”);

  17. Monostate • Solves the same problem as Singleton • All members are static • Constructors and destructor are private Class CompanyDb { private: static Db db; CompanyDb(); public: static Employee* get Employee( const char* name ); } Db CompanyDb::db = Db( “CompanyName” ); Employee* CompanyDb::getEmployee( const char* name ) { return db.find( “Employee”, name ); } Employee* emp = CompanyDb::getEmployee( “Leha” );

  18. Singleton vs. Monostate • Construction: • Singleton has lazy construction • Don’t pay unless you need it! • Monostates are always constructed • Singleton can have non-trivial constructors • Monostates can’t have non-trivial constructors • Destruction: • Singleton destruction is not defined • Monostate destructon is well-defined

  19. Strategy: Problem Problem: - different employees are paid differently - what if we need to add hourly paid manager ? - hierarchy is hard to maintain

  20. Strategy: Solution • PaymentPolicy specifies an algorithm for payment calculation

  21. Strategy: Pattern • Also known as: Policy • Benefits: • different strategies can be swapped in and out • context is closed to changes or additions of strategies

  22. Bridge: Problem • Problem: • Client code depends on platform • To support a new platform, we need to reproduce all Window’s derivatives

  23. Bridge 1 1 Window WindowImp drawText() drawText() XWindowImp PMWindowImp IconWindow DialogWindow drawText() drawText() Bridge: Solution • All operations on Window subclasses are implemented in terms of abstract operations from the WindowImp interface • Makes Window and its subclasses platform-independent • Q: How to make clients independent on WindowImp subclasses?

  24. Bridge: Pattern Also known as: Handle/Body Benefits: - Eliminates DIP & OCP violation - Increases maintainability

  25. Proxy: Problem Problem: we need to store our objects in relational database, but we don’t want the clients to depend upon the details of the database schema

  26. Proxy: Solution Solution: - use a surrogate that knows the details of the database - clients think they are interacting with RealEmployee

  27. Proxy: Pattern Also known as: Surrogate Applicability: - remote proxy - virtual proxy (creation of real object on demand) - protection proxy (for example: ACL support)

  28. Abstract Factory: Problem Problem: - creating objects creates a dependency on a concrete type - all other manipulations are done through interface !

  29. Factory: Solution Make a class whose responsibility is to make objects Making objects can’t be avoided, but can be contained

  30. Factory: Pattern Isolates concrete classes, makes Types family changes easier

  31. Stairway to Heaven: Problem Problem: - We wish to make an hierarchy of classes persistent, but we don’t want to depend upon the vendor of our database

  32. Stairway to Heaven: Solution Knowledge of business Knowledge of persistence • Use Adaptor pattern at each level in the hierarchy • Requires virtual multiple inheritance

More Related