design patterns n.
Skip this Video
Loading SlideShow in 5 Seconds..
Design Patterns PowerPoint Presentation
Download Presentation
Design Patterns

Loading in 2 Seconds...

play fullscreen
1 / 32

Design Patterns - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

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