Feb 4, 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

Feb 4, 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

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

Feb 4, 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.

Feb 4, 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

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

Feb 4, 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

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

Feb 4, 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.

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

Feb 4, 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

Feb 4, 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

Feb 4, 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?

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

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

Feb 4, 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?

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

Feb 4, Ron McFadyen18 Figure 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?

Feb 4, 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