1. Next Gen POS Example GRASP again

2. Same Patterns Different Example!

3. Apply Creator SalesLineItem

4. Fig. 17.12

5. Fig. 17.13

6. Contraindications When creation is complex: –Using recycled instances –External property values Then consider a helper class (Factory)

7. Information Expert Some class needs to know the grand total for a sale Information Expert: –Who has the information

8. Fig. 17.14

9. Fig. 17.15

10. Fig. 17.16

11. Responsibility Sale – knows sale total SalesLine Item – knows line item subtotal Product Description – knows price

12. Fig. 17.17 Calculate sale total

13. Discussion Information Expert Common guide to responsibilities Spreading of information means spreading of responsibilities Analogy to real world operations

14. Contraindications Example: who saves into the DB? This is not something to spread across classes –Separation of concerns –Cohesion

15. Low coupling Create a payment instance and associate it with a sale

16. Fig. 17.18 Create Payment

17. Fig. 17.19 Alternate Solution

18. Discussion Always consider this during all patterns! Kinds of coupling in Java, C++ or C# –By attribute reference to an instance –By call –A method refers to a type (param, local, etc.) –Direct or indirect subclass –Implement an interface

19. Discussion (cont’d) Reduce impact of later change Can’t reduce to zero coupling – goes against the central metaphor of object technology!

20. Contraindications High coupling to stable elements is ok

21. Controller What first element beyond the UI receives and coordinates a system operation?

22. Fig. 17.20 System Operations

23. Fig. 17.21

24. Fig. 17.22 Controller choices

25. Fig. 17.23 Allocation of Operations

26. Discussion Be careful of over responsibility

27. Fig. 17.24Desirable Coupling

28. Fig. 17.25 Less desirable!

29. Fig. 17.26 Bad for Cohesion

30. Fig. 17.27 Better

31. GRASP Patterns Patterns for object design Still requires judgment