1. SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html

2. Week 9 Design patterns

3. Gang Of Four Gamma, Helm, Johnson, Vlissides Some patterns in Larman, Chap. 23,… All patterns in XDE –As documentation. –As dynamic templates.

4. Present solutions to common software problems arising within a certain context Overview of Patterns Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs The Proxy Pattern 11 Proxy service Service service AbstractService service Client Help resolve key software design forces Flexibility Extensibility Dependability Predictability Scalability Efficiency Generally codify expert knowledge of design strategies, constraints & “best practices”

5. Design – Repeat Successes Has a (successful) similar product been built? Yes, then reuse domain specific: –Architectural Style (e.g. client/server, database, process control) Patterns. –Design Patterns (& idioms). Use Domain model as source of inspiration.

6. Design – New Application Area? Has a (successful) similar product been built? No, then choose among general: –Architectural Style (e.g. client/server, database, process control) Patterns. –Design Patterns (& idioms). Use Domain model as source of inspiration.

7. GoF Pattern Classification Behavioral Patterns Creational Patterns Structural Patterns

8. GoF Pattern Summary & Relationships

9. GoF Behavioral Patterns Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

10. GoF Creational Patterns Abstract Factory Builder Factory Method Prototype Singleton

11. GoF Structural Patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy

12. Command Pattern (for Front Controller) Problem: How to allow the same command to be invoked by –Menu selection –Alt-ctrl shortcut –Commandline text entry, etc How to allow (unlimited) undo/redo How to keep a log/audit/history of commands invoked How to allow “macro” commands to be defined

13. Command Pattern (for Front Controller) You have commands that need to be –executed, –undone, or –queued Command design pattern separates –Receiver from Invoker from Commands All commands derive from Command and implement do(), undo(), and redo() Also allows recording history, replay

14. Adapter Context / problem How to resolve incompatible interfaces, or provide a stable interface to similar components with different interfaces? Solution: Convert the original interface of a component into another interface, through an intermediate adapter object.

15. Adapter Suppose we have a tax calculation class (or external library) but the interface is not well suited for our application.

16. Adapter Adapter provides an interface suited to the application GoodAsGoldTaxProAdapter getTaxes( Sale ) : List of TaxLineItems computeTax(…):double GoodAsGoldTaxPro

17. Adapter (For More than One Class) What if more than one class (library) needs to be adapted?

18. Adapter

19. Singleton Pattern Notice: Constructor is no longer public. To access the instance use getUniqueInstance(). All other attribute and method declarations of C stay the same.

20. Facade

22. Factory Context / problem: Who should be responsible for creating objects when there are special considerations, such as complex creation logic, a desire to separate the creation responsibilities for better cohesion, and so forth? Solution: Create a Pure Fabrication object called a Factory.

23. (Abstract) Factory Example (GoF)

24. Factory (in EAs) FrontCommand + init ( ) + processRequest ( ) ViewStudInfoCommand + processRequest ( ) RemoveStudentCommand + processRequest ( ) FrontControllerServlet # processRequest ( ) - getCommand ( ) : FrontCommand - getCommandClass ( )

25. Strategy Context / problem: How to design for varying, but related, algorithms or policies? How to design for the ability to change (even dynamically) these algorithms or policies? Solution: Define each algorithm/policy/strategy in a separate class with a common interface

26. Strategy

27. How Do We Create a Strategy?

28. Composite (Larman05, 26.8) Context/problem How do you treat a group or composite structure of objects the same way (polymorphically) as a non-composite (atomic) object? Solution Define classes for composite and atomic objects so that they implement the same interface.

29. Composite: Ex. Class Diagram

30. Composite: Ex. Objects

31. Must “add” be implemented by Line? In C++ add declared virtual; subclass need not implement it. In Java if add is abstract, then subclasses must implement it. String add(Graphic g) { throw new UnsupportedOperationException(); } Can you think of a better solution?

32. Composite: Clients point-of-view

33. Composite Pricing Strategies Interface Realization

34. Observer Pattern

35. Observer How shall we have the display be updated? Why not … have the Sale inform the display when it changes value.

36. What is Wrong With This?

37. Observer Pattern Context / Problem: Different kinds of subscriber objects are interested in the state changes or events of a publisher object, and want to react in their own way when the publisher generates the event. …

38. Observer Pattern Solution: Define a “subscriber” or “listener” interface. Subscribers implement this interface. The publisher can dynamically register subscribers who are interested in an event, and notify them when an event occurs. Clarification: Publisher can dynamically process registration requests from subscribers.

39. Observer Pattern (GoF book)

40. Observers: Illustration