SOEN 343 Software Design

1. SOEN 343Software Design Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

2. Outline • GRASP Principles • Pure Fabrication • Indirection • Dice Game • GoF Design Patterns • Factory, Singleton, Adapter, Composite.

3. Pure Fabrication Problem: Existing objects, ie domain objects, are not appropriate to have the responsibility Solution suggested by Information Expert not appropriate Might violate high cohesion, low coupling Solution: Fabricate (ie create, make up) a new object to hold the responsibility

4. GRASP: Pure Fabrication • Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept—something made up, to support high cohesion, low coupling, and reuse. • Can you think of an example from EA?

5. GRASP: Pure Fabrication Design of objects • Representational decomposition • Behavorial decomposition It’s OK for OO software to have objects representing behaviour, ie use case, process, function, strategy, TS But do not overdo it All GoF design patterns are Pure Fabrications

6. Indirection Problem: How to assign responsibility to avoid direct coupling? How to de-couple objects? Solution: Assign responsibility to an intermediatory object to mediate between the two components Example: Adapter pattern Intermediatory to external tax calculators

7. Fig. 25.10

8. Indirection “Most problems in computer science can be solved by another level of indirection”

9. Patterns and Principles We have (and still are) studying: • Larman’s GRASP • GoF • Fowler’s EA The most fundamental are the principles.

10. GRASP: Interrelationships

11. Patterns apply principles, e.g. …

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

13. 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

14. GoF Pattern Summary & Relationships

15. GoF Pattern Classification • Behavioral Patterns • Creational Patterns • Structural Patterns

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

17. GoF Creational Patterns • Abstract Factory • Builder • Factory Method • Prototype • Singleton

18. Command Pattern(Week 1 and 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

19. Command Pattern (Week 1 and 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

20. Given a class C, how can we ensure that only one instance of C is ever created? Design Issue: Ensure No More Than One Instance of a Class is Created

21. Converting C to a Singleton.

22. 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

23. «Singleton» C.getUniqueInstance() public static C getUniqueInstance() { if(uniqueInstance == null) { uniqueInstance = new C(); } return uniqueInstance; }

24. Thread-safe Creation Method public staticsynchronized C getUn…() { … }

25. Singleton: Design Alternatives/Issues • Create a class with static attributes and methods. Trade-offs: consider how easy the following are: • Adapting the design so that x instances can be created (where x > 1). • Subclassing. • Passing the instance as a parameter. • … • (See Larman05, Section 26.5)

26. Singleton: Design Issues (Cont’d) • See Larman05, Section 26.5 for discussion of • Design trade-offs, including • eager/lazy evaluation of Singleton.uniqueInstance see.

27. Singleton & UML

28. Singleton & UML

29. Dice Game Simple game: Player rolls a dice Score is the face value of the dice

30. Client Cannot Tell …

31. Dice Game Refactoring We can apply: • Indirection principle. • Decouple DiceGame from Dice by inserting an IDice interface in between. • Introduce a Simple Factory class, DiceFactory. • Make DiceFactory a Singleton.

32. Dice Game: New Functionality Although we have ConstDice we still have a Problem: • Our DiceFactory only creates one type of IDice. Solutions: • Somehow we want the behavior of createDice() to vary.

33. DiceFactory.createDice(). • Possible solutions: • DiceFactory can read a System property to determine the class to instantiate (Larman05, p.441). • Add a method to factory: • Generalize our solution further: Abstract Factory. • Any of these solutions will finally allow us to create our test class, … e.g.

34. DiceGameTest JUnit TestCase public void testWinning() { int faceValue = 3; DiceFactory.theOne(). DiceGame game = new DiceGame(); game.roll(); assertEquals("face value", faceValue, game.getFaceValue()); assertTrue("won", game.won()); }

35. 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.

36. Factory Example

37. Larman’s comment on prev. figure • Note that the factory methods return objects types to an interfacre rather than a class so that the factory can return any implementation of the interface. • Factory methods can also

38. (Abstract) Factory Example (GoF)

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

40. New Version of Dice Game • Support using a pair of Dice. • How can this be added?

41. Multi-Dice Design

42. 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.

43. Dice Composite

44. Client Cannot Tell …

45. Composite: Ex. Objects

46. Composite: Ex. Class Diagram

47. 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?

48. Composite: Clients point-of-view

49. Interface Realization Composite Pricing Strategies

50. GoF Structural Patterns • Adapter • Bridge • Composite • Decorator • Facade • Flyweight • Proxy