1. Feb 4, 200291.3913 Ron McFadyen1 founded on principles of good OO design idea was first put forth by Christopher Alexander (1977) in their work concerning architectural design principles rules of thumb not new ideas notion of pattern is vague: “one person’s pattern is another person’s primitive building block” a pattern is a named problem/solution pair that can be applied in new contexts Patterns

2. Feb 4, 200291.3913 Ron McFadyen2 Guiding principles to help us assign responsibilities GRASP: –General Responsibility Assignment Software Patterns –Very very fundamental, simple, basic principles of object design. Fundamental Principles of Object Design GRASP Patterns

3. Feb 4, 200291.3913 Ron McFadyen3 Expert Creator Controller Low Coupling High Cohesion CH 16 GRASP Patterns

4. Feb 4, 200291.3913 Ron McFadyen4 (Information) Expert What is the most basic, general principle of responsibility assignment? Assign a responsibility to the object that has the information necessary to fulfill it. –“That which has the information, does the work.” –E.g., What software object calculates sales tax? What information is needed to do this? What object or objects has the majority of this information.

5. Feb 4, 200291.3913 Ron McFadyen5 Creator What object creates an X? –Ignores special-case patterns such as Factory. Choose an object C, such that: –C contains or aggregates X –C closely uses X –C has the initializing data for X

6. Feb 4, 200291.3913 Ron McFadyen6 Controller What object in the domain (or application layer) receives requests for work from the UI layer?

7. Feb 4, 200291.3913 Ron McFadyen7 Basic Principle: Interface objects should not have responsibility for handling system events Assign responsibility to a Controller, an object in the application/domain layer. Choose, or invent, an object in the application layer for this. Controller: a non-user interface object responsible for receiving or handling a system event. In the Process Sale Use Case, there are several system evetns: makeNewSale, enterItem, endSale, makePayment

8. Feb 4, 200291.3913 Ron McFadyen8 makeNewSale enterItem endSale makePayment Part of Figure 9.1 System Operations

9. Feb 4, 200291.3913 Ron McFadyen9 Candidates: –An object whose name reflects the use case. e.g. ProcessSaleHandler –An object whose name reflects the overall server, business, or large-scale entity. A kind of “façade” object e.g. Register Basic Principle: Interface objects should not have responsibility for handling system events Assign responsibility to the application/domain layer. Choose, or invent, an object in the application layer for this.

10. Feb 4, 200291.3913 Ron McFadyen10 Figure 16.16 Allocating System Operations Register has been chosen to handle all system operations Ch 20 shows the code for this Use Case handlers are chosen

11. Feb 4, 200291.3913 Ron McFadyen11 public void endSale ( ) { sale.becomeComplete(); } public void enterItem ( String id, int quantity ) { ProductSpecification spec = catalog.getSpecification( id ); sale.makeLineItem( spec, quantity ); } public void makeNewSale ( ) { sale = new Sale(); } public void makePayment (Money cashTendered ) { sale.makePayment( cashTendered ); } System event handling in Register The Controller doesn’t do much … delegates work to other objects … it receives the request and coordinates fulfillment

12. Feb 4, 200291.3913 Ron McFadyen12 The Controller pattern promotes reuse UI code is not intertwined with system event code UI can be replaced Multiple UIs could be utilized When a legal sequence of operations must occur, state information must be kept … the Controller object is an excellent choice for this information

13. Feb 4, 200291.3913 Ron McFadyen13 Low Coupling When we need to assign a responsibility to a class, we should do so such that coupling remains low. What does low coupling mean? … a class with high coupling has knowledge of, or is connected to, or relies on many other classes Example Assume we need to create a Payment instance … what class should do this?

14. Feb 4, 200291.3913 Ron McFadyen14 Creator pattern suggests Register Figure 16.9 Register creates Payment (Collaboration diagram)

15. Feb 4, 200291.3913 Ron McFadyen15 An alternative design is given in Figure 16.10 Which of the two designs, figures 16.9 and 16.10, supports lower coupling?

16. Feb 4, 200291.3913 Ron McFadyen16 High Cohesion When we need to assign a responsibility to a class, we should do so such that cohesion remains high cohesion: a measure of how strongly related and focussed the responsibilities of an object are Rule of Thumb (ROT): A class with high cohesion has a relatively small number of methods, with highly related functionality, and does not do too much work … it collaborates with others to get work done Example Assume we need to create a Payment instance … what class should do this?

17. Feb 4, 200291.3913 Ron McFadyen17 First solution given in Figure 16.11 (note this Sequence Diagram represents the same logic as the Collaboration diagram in Figure 16.9)

18. Feb 4, 200291.3913 Ron McFadyen18 Figure 16.12 gives a second solution (note this Sequence Diagram represents the same logic as the Collaboration diagram in Figure 16.10) Which solution supports higher cohesion for Register?

19. Feb 4, 200291.3913 Ron McFadyen19 Note, when considering which class to assign the responsibility of creating a payment, the text arrives at the same solution when applying both principles