Design Patterns

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