1. Chapter 17

2. GRASP General Responsibility Assignment Software Patterns (Principles) OOD: after identifying requirements, create domain model, define responsiblities and assign methods to classes define “messaging” (who sends the message) Patterns are a big part

3. Grasp Patterns Controller: go-between, UI and Domain –enhances low coupling –enhances reuse –represents “system” from the Use Case point of view –shared: User Controller handles CreateUser and DeleteUser use cases

4. Fig. 17.20 system-level operations

5. Fig. 17.21 big delegator

6. Fig. 17.22 “system” or “handler”

7. Fig. 17.23 each one handles a separate use case

8. Grasp Patterns Creator: not always a factory. B creates instances of A if: –B objects aggregate, record or closely use many A objects –B objects have all the info needed to create an A object When to use a factory? in cases of significant complexity (AvailableStack), conditional creation (froma family of similar classes)

9. Fig. 17.12

10. Fig. 17.13

11. Grasp Patterns High Cohesion: evaluative pattern; keep objects appropriately focused, manageable and understandable. –responsibilities are strongly related Low Cohesion: hard to comprehend, hard to reuse, hard to maintain and adverse to change

12. Fig. 17.26

13. Fig. 17.27

14. Grasp Patterns Indirection: low coupling through use of intermediary objects. –Controller is an example

15. Grasp Patterns Information Expert: Responsibility delegation principle –put the responsibility with the object having the most info needed to fulfill the responsibility –state the responsibility clearly first –Look in Design Model first, then the Domain Model –Expert is the most “intuitive” of patterns Who should be responsible for knowing the grand total of a sale?

16. Fig. 17.14 Domain Model Figure

17. Fig. 17.15

18. Fig. 17.16 getTotal() needs getSubtotal(). another Expert

19. Fig. 17.17 getSubtotal() needs getPrice() yet another Expert

20. Grasp Patterns Low Coupling: evaluative and supports: –lower dependency between the classes, –change in one class having lower impact on other classes, –higher reuse potential.

21. Fig. 17.18 Register unnecessarily put in the middle between Sale and Payment

22. Fig. 17.19 Register not involved in Payment

23. Grasp Patterns Polymorphism: variation of behaviours based on type assigned to types where the variation happens: –lower dependency between the classes, –change in one class having lower impact on other classes, –higher reuse potential.

24. Grasp Patterns Protected Variations: protects objects from variations in other objects: –wrap the variation behind an interface facade, –adapter pattern, –uses polymorphism

25. Grasp Patterns Pure Fabrication: no relationship to domain objects but: – achieves low coupling, high cohesion, and the reuse potential –alternative if Information Expert not available.

26. Object Design Overview Iterative context. requirements workshop 2-3 fully developed use cases high risks addressed some progress on domain model

27. Inputs and Relationship to OOD Use Case text: visible behaviour; our object will “realize” this behaviour System Sequence Diagrams: system-level messages. These are the initial messages in our program sequence diagrams

28. OOD Activities: Tools: GRASP, GoF Design Patterns Metaphor: assign responsibilities to collaborating objects Modeling Purpose: Understanding, not documentation. Next slide shows some activity inputs and outputs

29. Fig. 17.1 Sale addLineItem 1

30. Responsibility Driven Design Responsibility: Obligation or contract Kinds of Responsibilities: –Doing: doing, initiating in others, controlling activities –Knowing: private data, related objects, calculations (guided by Domain Model and low rep'l gap –Collaboration: objects need help from otehrs Example: A Sale objects is responsible for creating a SalesLineItem object and knowing the running total

31. GRASP Principles A learning aid for object design based on patterns for assigning responsibilties Relationship to UML and Responsibilities Sequence Diagrams give us an opportunity to assign responsibilities

32. Fig. 17.2 Sales objects responsible for creating payment objects

33. What are Patterns? a software system whose design is guided by the use of general principles or idomatic solutions Pattern NameInformation Expert ProblemWhat is a basic principle by which to assign responsiblilities to objects? SolutionAssign responsibilities to the class that possesses the most information neededto fulfill it.

34. What are Patterns? A pattern is a named description of a (problem, solution) pair can be applied in a new context. patterns come with advice on how they should be used. Patterns are known by their names “We'll expose the services of the persistence subsystem with a Facade, use an Abstract Factory for the Mappers classes and Proxy for lazy materialization”

35. Example In a molopoly game what object creates (invokes creation of) the individual squares that players can land on? –B objects aggregate, record or closely use many A objects –B objects have all the info needed to create an A object A = Square ==> B = ?

36. Fig. 17.3 Creator Pattern

37. Fig. 17.4

38. Fig. 17.5

39. Example In a molopoly game what objects know about a Square (given a key or square name)? Such an object is an Information Expert. Again the answer is Board; this is reassuring.

40. Fig. 17.6

41. Example All other things being equal we should prefer a solution that exhibits low coupling. Low coupling tends to reduce the time, effort and defects associated with mmodifying software. Does Expert support Low Coupling?

42. Fig. 17.7

43. Example UI objects should not contain “business” logic UI objects should delegate any needed domain task to another. The Controller patter answers the question “What first object after the UI layer should receive a message from the UI layer for service?

44. System Sequence Diagram What class should have this responsibility?

45. Controller Design Controllers should either: –represent the overall system ( a device the software is running within) or a major subsystem; both variations of the Facade pattern, or –represent a use case scenario context (such as a session controller)

46. Fig. 17.9

47. Example In the monopoly game, a MonopolyGame class represents the overall system. In the ATM example the ATM represents the device the software is running within. a PlayMonopolyGameHandler acts as a Session Controller (but we only have one session!).

48. Fig. 17.10 design based on Controller

49. :MonopolyGame play game what next?

50. Example Next slide shows two design approaches possible. Either one class does all the work or else work is delegated to other classes. Lession to learn: low cohesion leads to high coupling.

51. Fig. 17.11

52. Fig. 17.24

53. Fig. 17.25