1. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Software Engineering October 17, 2001 Design Patterns Joseph Conron Computer Science Department New York University jconron@cs.nyu.edu

2. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 How to Become a Chess Master  First learn rules and physical requirements  e.g., names of pieces, legal movements, chess board geometry and orientation, etc.  Then learn principles  e.g., relative value of certain pieces, strategic value of center squares, power of a threat, etc.  However, to become a master of chess, one must study the games of other masters  These games contain patterns that must be understood, memorized, and applied repeatedly  There are hundreds of these patterns

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 How to Become a Software Design Master  First learn the rules  e.g., the algorithms, data structures and languages of software  Then learn principles  e.g., structured programming, modular programming, object oriented programming, etc.  However, to truly master software design, one must study the designs of other masters  These designs contain patterns that must be understood, memorized, and applied repeatedly  There are hundreds of these patterns

4. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 A Design Pattern: … describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use the this solution a million times over, without ever doing it the same twice …captures design knowledge  Higher level than classes or data structures (link lists,binary trees...)  Lower level than application frameworks …is a modifiable design

5. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 What makes a design modifiable?  Low coupling and high coherence  Clear dependencies  Explicit assumptions How do design patterns help?  They are generalized from existing systems  They provide a shared vocabulary to designers  They provide examples of modifiable designs  Abstract classes  Delegation

6. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Principles from Design Patterns  Program to an interface and not to an implementation.  define the top of any class hierarchy with an abstract class which implements no methods, but simply defines the methods that class will support.  Favor object composition over inheritance.  Don’t rely only on class inheritance to add new functionality.

7. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Reuse  Main goal:  Reuse knowledge from previous experience to current problem  Reuse functionality already available  Two ways to get new functionality:  Inheritance (also called White-box Reuse)  New functionality is obtained by inheritance.  Composition (also called Black Box Reuse)  New functionality is obtained by aggregation  The new object with more functionality is an aggregation of existing components

8. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Implementation Inheritance vs Interface Inheritance  Implementation inheritance  Also called class inheritance  Goal: Extend an applications’ functionality by reusing functionality in parent class  Inherit from an existing class with some or all operations already implemented  Interface inheritance  Also called subtyping  Inherit from an abstract class with all operations specified, but not yet implemented

9. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Implementation Inheritance  A very similar class is already implemented that does almost the same as the desired class implementation.  Problem with implementation inheritance: Some of the inherited operations might exhibit unwanted behavior. What happens if the Stack user calls Remove() instead of Pop()?  Example: I have a List class, I need a Stack class. How about subclassing the Stack class from the List class and providing three methods, Push() and Pop(), Top()? Add() Remove() List Push() Pop() Stack Top() “Already implemented”

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Interface inheritance vs. implementation inheritance Interface inheritance  separates interface and implementation  implementations may be transparently substituted  decreases coupling  Implementation inheritance (“class inheritance”)  introduces dependencies among an ancestor and its descendents (inherited state)  mixes interface specification and implementation  can be achieved with delegation instead  The Design Patterns book shows how to avoid implementation inheritance with a mix of interface inheritance and delegation

11. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Composition  New object is formed by composing it from existing objects  Requires new objects have well-defined interfaces  Since objects are accessed solely through their interfaces, encapsulation is preserved:  Objects can be replaced at runtime rather than compile time  Fewer implementation dependencies

12. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Delegation  Delegation is a way of making composition (for example aggregation) as powerful for reuse as inheritance  In Delegation two objects are involved in handling a request  A receiving object delegates operations to its delegate.  The developer can make sure that the receiving object does not allow the client to misuse the delegate object Client Receiver Delegate Delegates to calls

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Delegation or Inheritance?  Delegation  Pro:  Flexibility: Any object can be replaced at run time by another one (as long as it has the same type)  Con:  Inefficiency: Objects are encapsulated.  Inheritance  Pro:  Straightforward to use  Supported by many programming languages  Easy to implement new functionality  Con:  Inheritance exposes a subclass to the details of its parent class  Any change in the parent class implementation forces the subclass to change (which requires recompilation of both)

14. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Delegation instead of Inheritance  Delegation: Catching an operation and sending it to another object. +Add() +Remove() List Stack +Push() +Pop() +Top() Stack Add() Remove() List +Push() +Pop() +Top()

15. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Many design patterns use a combination of inheritance and delegation

16. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 On to the Patterns!  A Design Pattern has 4 basic parts: 1.Name 2.Problem 3.Solution 4.Consequences and trade-offs of application  A Design Pattern is language and implementation independent

17. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Design Patterns: the basic 23 patterns from GOF Scope:domain over which a pattern applies Purpose: reflects what a pattern does

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 A Pattern Taxonomy  Creational Patterns  Abstract the instantiation process.  Make a system independent from the way its objects are created, composed and represented.  Example: Factory  Structural Patterns  Adapters, Bridges, Facades, and Proxies are variations on a single theme:  They reduce the coupling between two or more classes  They introduce an abstract class to enable future extensions  Encapsulate complex structures  Behavioral Patterns  Concerned with algorithms and the assignment of responsibilies between objects: Who does what?  Characterize complex control flow that is difficult to follow at runtime.  Example: Observer, Iterator, Command

19. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Factory Pattern (Creational)  Factory pattern is one that returns an instance of one of several possible classes depending on the data provided to it.  Usually all of the classes it returns have a common parent class and common methods.  Each factory produced class performs a task differently and is optimized for different kinds of data.

20. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Factory Pattern

21. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 When to Use a Factory Pattern  You should consider using a Factory pattern when  A class can’t anticipate which kind of class of objects it must create.  A class uses its subclasses to specify which objects it creates.  You want to localize the knowledge of which class gets created.  There are several similar variations on the factory pattern to recognize. 1.The base class is abstract and the pattern must return a complete working class. 2.The base class contains default methods and is only sub-classed for cases where the default methods are insufficient. 3.Parameters are passed to the factory telling it which of several class types to return. In this case the classes may share the same method names but may do something quite different.

22. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Adapter Pattern (Structural)  “Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces  Used to provide a new interface to existing legacy components (Interface engineering, reengineering).  Also known as a wrapper  Two adapter patterns:  Class adapter:  Uses multiple inheritance to adapt one interface to another  Object adapter:  Uses single inheritance and delegation

23. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23  Delegation is used to bind an Adapter and an Adaptee  Interface inheritance is use to specify the interface of the Adapter class.  Target and Adaptee (usually called legacy system) pre-exist the Adapter.  Target may be realized as an interface in Java. Adapter pattern Client Target Request() Adaptee ExistingRequest() Adapter Request() adaptee

24. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Adapter pattern example public class ServicesEnumeration implements Enumeration { public boolean hasMoreElements() { return this.currentServiceIdx <= adaptee.numServices(); } public Object nextElement() { if (!this.hasMoreElements()) { throw new NoSuchElementException(); } return adaptee.getService(this.currentSerrviceIdx++); } Client Enumeration hasMoreElements() nextElement() RegisteredServices numServices(); getService(int num); ServicesEnumeration hasMoreElements() nextElement() adaptee

25. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25 Bridge Pattern (Structural)  Use a bridge to “decouple an abstraction from its implementation so that the two can vary independently”. (From [Gamma et al 1995])  Also know as a Handle/Body pattern.  Allows different implementations of an interface to be decided upon dynamically.

26. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26 RefinedAbstraction Implementor imp Concrete ImplementorA Concrete ImplementorB provides Abstraction Subsystem Bridge pattern (UML)

27. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27 ODBC Implementation ODBC imp Oracle ODBC Driver DB2 ODBC Driver Informix ODBC Driver Bridge Pattern Example Abstracting database vendors: removing the dependency from database vendors from the systems provides more flexibility.

28. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28 Using a Bridge  The bridge pattern is used to provide multiple implementations under the same interface.  The Bridge pattern is intended to keep the interface to your client program constant while allowing you to change the actual kind of class you display or use. This can SAVE you from recompiling a complicated set of user interface modules, and only require that you recompile the bridge itself and the actual end display class.  You can extend the implementation class and the bridge class separately, and usually without much interaction with each other.

29. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29 Proxy Pattern (Structural)  What is expensive?  Object Creation  Object Initialization  Defer object creation and object initialization to the time you need the object  Proxy pattern:  Reduces the cost of accessing objects  Uses another object (“the proxy”) that acts as a stand-in for the real object  The proxy creates the real object only if the user asks for it

30. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30 Proxy pattern  Interface inheritance is used to specify the interface shared by Proxy and RealSubject.  Delegation is used to catch and forward any accesses to the RealSubject (if desired)  Proxy patterns can be used for lazy evaluation and for remote invocation.  Proxy patterns can be implemented with a Java interface. Subject Request() RealSubject Request() Proxy Request() realSubject

31. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31 Proxy Example  Problem: provide access protection to stock/bond portfolio  To access portfolio, Broker can use PortfolioProxy.  PortfolioProxy first checks with the if the invoking Broker has legitimate access. Once access has been granted, PortfolioProxy delegates the operation to the actual Portfolio object.  One Access association can be used to control access to many Portfolios.

32. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32 Proxy Example (Protection) Portfolio buy() sell() estimateYield() 1 1 * 1 Broker buy() sell() estimateYield() Access isAccessible(op) PortfolioProxy Dynamic access implemented with a protection Proxy.

33. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33 Proxy Applicability  Remote Proxy  Local representative for an object in a different address space  Virtual Proxy  Object is too expensive to create or too expensive to download  Proxy is a stand-in  Protection Proxy  Proxy provides access control to the real object  Useful when different objects should have different access and viewing rights for the same document.  Example: Grade information for a student shared by administrators, teachers and students.

34. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34 Command Pattern (Behavioral)  You want to build a user interface  You want to provide menus  You want to make the user interface reusable across many applications  You cannot hardcode the meanings of the menus for the various applications  The applications only know what has to be done when a menu is selected.  Such a menu can easily be implemented with the Command Pattern

35. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35 Command pattern  Client creates a ConcreteCommand and binds it with a Receiver.  Client hands the ConcreteCommand over to the Invoker which stores it.  The Invoker has the responsibility to do the command (“execute” or “undo”). Command execute() Receiver action() Client Invoker ConcreteCommand execute() binds

36. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36 Menu Example Command execute() Document action() Application Menu Item Copy execute() binds Menu * Paste execute() Client Invoker: Asks the Command object To carry out the request Concrete Command Receiver *

37. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37 Command pattern Applicability  “Encapsulate a request as an object, thereby letting you  parameterize clients with different requests,  queue or log requests, and  support undoable operations.”  Uses:  Undo queues  Database transaction buffering

38. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38 Structuring the objects Menu MoveCommand Rectangle Editor UndoQueue Invoker (Boundary objects) ConcreteCommands (Control objects) Receiver (Entity objects) Triangle Circle

39. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 39 Command pattern: typical sequence aRectangle: Rectangle anEditor moveCommandundoQueue newCommand(info) store(MoveCommand1) execute() move(x, y) aUser Drags mouse “MoveCommand1 ”

40. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 40 Observer pattern (Behavioral)  “Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.” (p. 293)  Also called “Publish and Subscribe”  Uses:  Maintaining consistency across redundant state  Optimizing batch changes to maintain consistency

41. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 41 Observer pattern (continued) 9DesignPatterns2.ppt Observers Subject

42. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 42 Observer pattern (continued) Observer update() Subject attach(observer) detach(observer) notify() ConcreteSubject getState() setState(newState) subjectState ConcreteObserver update() observerState observers subject *  The Subject represents the actual state, the Observers represent different views of the state.  Observer can be implemented as a Java interface.  Subject is a super class (needs to store the observers vector) not an interface.

43. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 43 Sequence diagram for scenario: Change filename to “foo” getState() update() aListViewanInfoViewaFile setState(“foo”) notify() Attach() “foo” Subject goes through all its observers and calls update() on them, asking for the new state is decoupled from the notification

44. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 44 Animated Sequence diagram getState() aListViewanInfoViewaFile notify() Attach() “foo” setState(“foo”) update()

45. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 45 Observer pattern implementation in Java // import java.util; public class Observable extends Object { public void addObserver(Observer o); public void deleteObserver(Observer o); public boolean hasChanged(); public void notifyObservers(); public void notifyObservers(Object arg); } public abstract interface Observer { public abstract void update(Observable o, Object arg); } public class Subject extends Observable{ public void setState(String filename); public string getState(); }

46. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 46 Strategy Pattern  Many different algorithms exists for the same task  Examples:  Breaking a stream of text into lines  Parsing a set of tokens into an abstract syntax tree  Sorting a list of customers  The different algorithms will be appropriate at different times  Rapid prototyping vs delivery of final product  We don’t want to support all the algorithms if we don’t need them  If we need a new algorithm, we want to add it easily without disturbing the application using the algorithm

47. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 47 Strategy Pattern Strategy AlgorithmInterface Context ContextInterface() ConcreteStrategyC AlgorithmInterface() Strategy * ConcreteStrategyB AlgorithmInterface() ConcreteStrategyA AlgorithmInterface()

48. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 48 Applying a Strategy Pattern in a Database Application Strategy Sort() Database Search() Sort() ShellSort Sort(CustomerList) Strategy * QuickSort Sort(CustomerList) BubbleSort Sort(CustomerList)

49. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 49 Applicability of Strategy Pattern  Many related classes differ only in their behavior. Strategy allows to configure a single class with one of many behaviors  Different variants of an algorithm are needed that trade-off space against time. All these variants can be implemented as a class hierarchy of algorithms

50. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 50 Summary  Structural Patterns  Focus: How objects are composed to form larger structures  Problems solved:  Realize new functionality from old functionality,  Provide flexibility and extensibility  Behavioral Patterns  Focus: Algorithms and the assignment of responsibilities to objects  Problem solved:  Too tight coupling to a particular algorithm  Creational Patterns  Focus: Creation of complex objects  Problems solved:  Hide how complex objects are created and put together

51. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 51 Conclusion  Design patterns  Provide solutions to common problems.  Lead to extensible models and code.  Can be used as is or as examples of interface inheritance and delegation.  Apply the same principles to structure and to behavior.  Design patterns solve all your software engineering problems