1. Object-Oriented Design Part 2 http://flic.kr/p/btp5ZK

2. Responsibility-Driven Design Frames object design as deciding How to assign responsibilities to objects How objects should collaborate – What role each each object should play in a collaboration http://flic.kr/p/btp5ZK

3. What is meant by responsibilities An object’s obligations (and thus behavior) Two types: Doing responsibilities, e.g.: – Creating an object – Calculating something – Initiating action on other objects – Coordinating activities among other objects Knowing responsibilities, e.g.: – Knowing about data – Knowing about related objects – Knowing about things it can derive or calculate

4. Domain Model attributes inspire knowing responsibilities Design Analysis Register knows its IDSale knows its time

5. What is meant by collaboration? Objects interact (via messages) to fulfill responsibilities Example: Register collaborates with Sale and Payment to process a payment (its responsibility)

6. Responsibilities vary in granularity “Big” responsibilities may require collaborations of many objects “Small” responsibilities may be fulfilled by a single object

7. How to assign responsibilities and design collaborations? No mechanical method – Requires expert human judgment! But there’s hope: patterns! http://flic.kr/p/4tTsQe

8. Patterns Repeatable solution for a commonly occurring software problem Codify existing tried-and-true knowledge Provide vocabulary

9. Point of Sale Example Think of a cashier’s register – Cashier scans or manually enters the price of items – All items sold make up a sale – Payment is received, change is given – A receipt is generated

10. What object should be responsible for creating a SalesLineItem? POS Design Question

11. Creator Pattern Assign class B responsibility of creating instances of class A if 1+ of the following: B “contains” A B records A B closely uses A B has initializing data for A – B is an expert with respect to creating A

12. What object should be responsible for creating a SalesLineItem? The Creator Pattern says that Sale should create SalesLineItem POS Design Question

13. How a Sale object might create a SalesLineItem object : Register : Sale

14. What object should be responsible for knowing the grand total of a sale? POS Design Question

15. Information Expert Pattern Assign a knowing responsibility to the class that has the information necessary to fulfill the responsibility

16. What object should be responsible for knowing the grand total of a sale? POS Design Question The Information Expert Pattern says that Sale should know the grand total

17. How Sale might calculate the grand total Sale will need a method for computing the total

18. How Sale might calculate the grand total Sales will get the subtotal from each SalesLineItem

19. How Sale might calculate the grand total SalesLineItem will need to get the price from ProductDescription

20. How Sale might calculate the grand total These three objects collaborate to compute the grand total Each one must fulfill its own set of responsibilities

21. What class should be responsible for this? POS Design Question Assume we need to create a Payment instance and associate it with a Sale instance

22. One possible design: Register creates Payment

23. Another possible design: Sale creates Payment

24. Which design is better?

25. Low Coupling Pattern Assign responsibilities so that coupling stays low Coupling: measure of how strongly one element is connected to others has knowledge of others relies on others

26. Common types of coupling in OO languages Class C is coupled to class D if C has instance variable that refers to D C invokes method/function of D C method parameter or local variable references D C is direct or indirect subclass of D C implements interface D

27. Problems with high coupling Given class C highly coupled to class D: Changes in D may force changes in C Harder to understand C in isolation Harder to reuse C because of dependencies on D

28. Which design has lower coupling? Assuming Sale will eventually need to be coupled with Payment First design adds extra coupling between Register and Sale so second design has lower coupling

29. Critique: Other considerations may override preference toward low coupling Strength of coupling should be balanced against other design considerations Critique: High coupling to stable/pervasive elements is seldom a problem Consider coupling to Java standard libraries

30. Review of Key OO Concepts Objects/Classes Information Hiding – The ability to protect class contents from external entities – Private/Protected Inheritance – The ability for a class to extend and override functionality of another class – Generalization/Specification Interface – A contract of functionality other classes can implement Polymorphism – The ability to create an entity that has more than one type

31. Design Advice Inputs for your design – Use Cases – Sequence Diagrams – Prototypes – Dataflow Diagrams – Architecture Diagrams

32. Best practices Use known design patterns – Creator – Information Expert – More to come on the next class Take advantage of tried-and-true libraries – Don’t reimplement something that’s already been done Ex: Use known encryption libraries, they have been thoroughly tested and much less likely to have bugs

33. Vision Statement Next week we’ll start Agile Everyone will create a new vision statement with a new topic using the same specification as HW 0 Consider a solution that lends itself to an iterative design These will be due next Monday

34. What’s next for you? HW 3 is due tomorrow by midnight HW 4 is posted Think about your new vision statements