1. Design Patterns Copyright © Vyacheslav Mukhortov, Nikita Nyanchuk-Tatarskiy, 2001-2004 Copyright © INTEKS LLC, 2003-2004

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:  Creational patterns – abstract the instantiation process and make a system independent on how objects are created  Abstract Factory, Factory Method, Singleton  Structural patterns – solve objects composition problems  Adapter, Bridge, Decorator, Proxy  Behavioral patterns - algorithms and the assignment of responsibilities between objects  Chain of Responsibility, Command, Iterator, Observer, State, Strategy

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

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

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

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

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

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

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

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

12. Solution Server provides interface for client to use

13. Pattern: Abstract Client 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: 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 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”); 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 ); };

17. Monostate Solves the same problem as Singleton All members are static Constructors and destructor are private Class CompanyDb { private: 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: - different employees are paid differently - what if we need to add hourly paid manager ? - hierarchy is hard to maintain

20. 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: - Client code depends on platform - To support a new platform, we need to reproduce all Window’s derivatives

23. 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? Window drawText() WindowImp drawText() 11 XWindowImp drawText() PMWindowImp drawText() DialogWindowIconWindow Bridge

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

25. Proxy Problem: We need to optimize object access in order to make resource allocation operations on demand

26. Solution Solution: - use a surrogate that will initiate create operation on demand - clients can treat RealImage and ImageProxy as similar objects.

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: - creating objects creates a dependency on a concrete type - all other manipulations are done through interface !

29. 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: - We wish to make an hierarchy of classes persistent, but we don’t want to depend upon the vendor of our database

32. Solution Use Adaptor pattern at each level in the hierarchy  Requires virtual multiple inheritance Knowledge of persistence Knowledge of business

33. Visitor What if we need to configure modems differently for different operating systems?

34. Visitor Problem? ISP violation. Hard to support new OSes.

35. Solution

36. Issues Problem? A cycle involving modem implementations. Hard to support new modem types.

37. New Solution: Acyclic Visitor