SOEN 6011 Software Engineering Processes

1. SOEN 6011Software 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. Overview of Patterns • Present solutions to common software problems arising within a certain context • Help resolve key software design forces • Flexibility • Extensibility • Dependability • Predictability • Scalability • Efficiency Client Proxy Service AbstractService service service service • Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs • Generally codify expert knowledge of design strategies, constraints & “best practices” 1 1 The Proxy Pattern

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. Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor GoF Behavioral Patterns

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 / problemHow 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. GoodAsGoldTaxProAdapter getTaxes( Sale ) : List of TaxLineItems GoodAsGoldTaxPro computeTax(…):double Adapter • Adapter providesan interface suitedto the application

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

18. Adapter

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

20. Facade

21. 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) FrontControllerServlet FrontCommand # processRequest ( ) + init ( ) - getCommand ( ) : FrontCommand + processRequest ( ) - getCommandClass ( ) RemoveStudentCommand ViewStudInfoCommand + processRequest ( ) + processRequest ( )

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. Interface Realization Composite Pricing Strategies

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