1. Design Patterns David Talby

2. This Lecture n The rest of the pack u Working over a network F Proxy, State, Chain of Responsibility u Working with external libraries F Adapter, Façade u Coding partial algorithms F Template Method u Special-case patterns F Interpreter, Momento u Summary

3. 16. Proxy n Provide a placeholder for another object, to control access to it n For example, we’d like to defer loading the images of a document until we must display it

4. The Requirements n Only load images when required n Client code must not know whether lazy load is used or not n Images may be loaded from a file, a database or a network u Such code should be encapsulated u Should be easy to add variations, such as security and compression

5. The Solution n Define a new graphic ImageProxy, which holds an image’s file name n Holds an uninitialized Image object n When its draw() method is called: draw() { if (image == NULL) image = load(filename); image->draw(); }

6. The Solution II n Many ways to implement load : u Read from a file or database u Use a complex network protocol u Use encryption, compression, …  Compute the returned object n Any such complex logic is well encapsulated in the proxy n The proxy can hold part of Image’s data for efficiency

7. The UML

8. The Fine Print n The Proxy vocabulary u Virtual Proxy – creates expensive objects on demand u Remote Proxy – a local representative of an object in another address space u Protection Proxy – controls access to the original object u Smart Pointers – overload regular pointers with additional actions

9. The Fine Print II n Uses of smart pointers u Reference counting u Synchronization (lock management) u Profiling and statistics u Copy-on-write u Cache coherence u Pooling Smart pointers are easy in C++ thanks to overloading = and –>

10. The Fine Print III n Proxy is very much like Decorator n Decorator = functional addition n Proxy = technical addition

11. Known Uses n Every programming language n Every middleware package n Every database package

12. 17. State n Allow an object to alter its behavior when its internal state changes n For example, most methods of a TCPConnection object behave in different ways when the connection is closed, established or listening n How do we encapsulate the logic and data of every state?

13. The Requirements n A class has a state diagram, and many methods behave in wildly different ways in different states n When in a state, only allocate memory for data of that state n The logic of a specific state should be encapsulated

14. Pattern of Patterns n Encapsulate the varying aspect u State of an object n Interfaces u Let’s have a TCPState interface that has all the state-sensitive methods n Inheritance describes variants u TCPEstablished, TCPListen and TCPClosed implement the interface n Composition allows a dynamic choice between variants

15. The Solution II n A TCPConnection codes state transitions and refers to a TCPState

16. The UML

17. The Fine Print n In complex cases it is better to let states define transitions, by adding a SetState method to Context n States may be created on-demand or on Context ’s creation n This pattern is really a workaround for the lack of dynamic inheritance n State is very much like Strategy u State = Many (small) actions u Strategy = One (complex) action

18. Known Uses n Streams and connections n Different tools on a drawing program u Select, Erase, Crop, Rotate, Add, …

19. 18. Chain of Responsibility n Decouple the sender and receiver of a message, and give more than one receiver a chance to handle it n For example, a context-sensitive help system returns help on the object currently in focus n Or its parent if it has no help n Recursively

20. The Requirements n Allow calling for context-sensitive help from any graphical object n If the object can’t handle the request (it doesn’t include help), it knows where to forward it n The set of possible handlers is defined and changed dynamically

21. The Solution n Define a HelpHandler base class: class HelpHandler { handleHelp() { if (successor != NULL) successor->handleHelp(); } HelpHandler* successor = NULL; }

22. The Solution II n Class Graphic inherits HelpHandler n Graphic descendants that have help to show redefine handleHelp : handleHelp() { ShowMessage(“Buy upgrade”); } n Either the root Graphic object or HelpHandler itself can redefine handleHelp to show a default

23. The UML

24. The Fine Print n Receipt isn’t guaranteed n Usually parents initialize the successor of an item upon creation u To themselves or their successor n The kind of request doesn’t have to be hardcoded: class Handler { handle(Request* request) { // rest as before

25. Known Uses n Context-sensitive help n Messages in a multi-protocol network service n Handling user events in a user interface framework n Updating contained objects/queries in a displayed document

26. 19. Adapter n Convert the interface of a class into another that clients expect n For example, We’d like to use advanced Text and SpellCheck component that we bought n But Text doesn’t inherit Graphic or supply iterators, and SpellCheck doesn’t inherit Visitor n We don’t have their source code

27. The Requirements n Convert the interface of a class into a more convenient one n Without the class’s source code u No compilation dependencies n The class may be a module in a non-object oriented language

28. The Solution n If you can’t reuse by inheritance, reuse by composition: class TextGraphic : public Graphic { public: void draw() { text->paint(); } // other methods adapted... private: BoughtTextComponent *text; }

29. The Requirements II n Stacks and queues are kinds of lists, but they provide less functionality n LinkedQueue is a linked list implementation of interface Queue n We’d like to reuse LinkedList for it n Inheritance can’t be used if children offer less than their parents

30. The Solution II n Object Adapter u Class LinkedQueue will hold a reference to a LinkedList and delegate requests to it n Class Adapter u Class LinkedQueue will inherit from both Queue and LinkedList u Method signatures in both classes must match n In C++ class adapters are safer thanks to private inheritance

31. The UML n Object Adapter:

32. The UML II n Class Adapter:

33. Known Uses n Using external libraries n Reusing non O-O code n Limiting access to classes

34. 20. Facade n Provide a unified interface to a set of interfaces of subsystems n For example, a compiler is divided into many parts u Scanner, parser, syntax tree data structure, optimizers, generation, … n Most clients just compile files, and don’t need to access inner parts

35. The Requirements n Provide a simple, easy to use and remember interface for compilation n Keep the flexibility to tweak inner parts when needed

36. The Solution n Define a façade Compiler class as the entry point to the system

37. The UML

38. The Fine Print n Advantages of a façade: u Most users will use a very simple interface for the complex system u Clients are decoupled from the system u Makes it easier to replace the entire system with another n Packages (Java) and namespaces (C++) are ways to define “systems” of classes and decide which classes are visible to the system’s clients

39. Known Uses n A Compiler or XML Parser n Browsing objects at runtime n The Choices O-O operating system u The File and Memory systems

40. 21. Template Method n Define the skeleton of an algorithm and let subclasses complete it n For example, a generic binary tree class or sort algorithm cannot be fully implemented until a comparison operator is defined n How do we implement everything except the missing part?

41. The Requirements n Code once all parts of an algorithm that can be reused n Let clients fill in the gaps

42. The Solution n Code the skeleton in a class where only the missing parts are abstract: class BinaryTree { void add(G* item) { if (compare(item, root)) // usual logic } int compare(G* g1, G* g2) = 0; }

43. The Solution II n Useful for defining comparable objects in general: class Comparable { operator <(Comparable x) = 0; operator >=(Comparable x) { return !(this < x); } operator >(Comparable x) { return !(this < x) && !(this == x); }

44. The Solution III n A very common pattern: class HelpHandler { handleHelp() { if (successor != NULL) successor->handleHelp(); } HelpHandler* successor = NULL; }

45. The UML

46. The Fine Print n The template method is public, but the ones it calls should be protected n The called methods can be declared with an empty implementation if this is a common default n This template can be replaced by passing the missing function as a template parameter n Java sometimes requires more coding due to single inheritance

47. Known Uses n So fundamental that it can be found almost anywhere n Factory Method is a kind of template method specialized for creation

48. 22. Interpreter n Given a language, define a data structure for representing sentences along with an interpreter for it n For example, a program must interpret code or form layout, or support search with regular expression and logical criteria n Not covered here

49. 23. Momento n Without violating encapsulation, store an object’s internal state so that it can be restored later n For example, a program must store a simulation’s data structures before a random or approximation action, and undo must be supported n Not covered here

50. Summary n O-O concepts are simple u Objects, Classes, Interfaces u Inheritance vs. Composition n Open-Closed Principle n Single Choice Principle n Pattern of patterns

51. The Benefits of Patterns n Finding the right classes n Finding them faster n Common design jargon n Consistent format n Coded infrastructures n and above all: Pattern = Documented Experience