Oct 3, Ron McFadyen1 GRASP Patterns 1.Expert 2.Creator 3.Controller 4.Low Coupling 5.High Cohesion

Oct 3, Ron McFadyen2 Expert n Assign a responsibility to the object that has the information necessary to fulfill it. – “That which has the information, does the work.” – Not a sophisticated idea - rather, it is common sense – E.g., What software object calculates grand total? What information is needed to do this? What object or objects has the majority of this information.

Oct 3, Ron McFadyen3 Expert Example. In the NextGEN POS application, it is necessary to know the grand total of a sale. Where should that responsibility be placed? {We will be assigning a few responsibilities in this example} Expert suggests that we should look for a class that has the information needed to determine the grand total. If our design is just beginning, we look at the Domain Model and bring the pertinent conceptual classes into the class model Pages

Oct 3, Ron McFadyen4 What information is needed to determine the grand total? It is necessary to know all the SalesLineItem instances of a sale and to sum of their subtotals. A Sale instance is aware of these … Sale is the Expert choice for having the responsibility of knowing the grand total.

Oct 3, Ron McFadyen5 Expert leads us to place the method getTotal() in Sale

Oct 3, Ron McFadyen6 A line item knows its quantity and the associated Product, so it is the expert … SalesLineItem should determine the line item subtotal

Oct 3, Ron McFadyen7 Only the Product Specification knows the price; so Product Specification needs a method...

Oct 3, Ron McFadyen8 Creator n What object should have the responsibility to create an X? – Ignores special-case patterns such as Factory. n Choose an object C, such that: – C contains or aggregates X – C closely uses X – C records instances of X objects – C closely uses X objects – C has the initializing data for X

Oct 3, Ron McFadyen9 Example: Who should be responsible for creating a SalesLineItem? Since Sale “contains” SalesLineItems, Creator suggests Sale as the candidate for this responsiblity

Oct 3, Ron McFadyen10 :Register :SalesLineItem makeLineItem(qty) create(qty) :Sale We assign the responsibility of creating a SalesLineItem to Sale – Sale will have a method makeLineItem

Oct 3, Ron McFadyen11 What object in the domain (or application layer) receives requests for work from the UI layer? Controller

Oct 3, Ron McFadyen12 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 events: makeNewSale, enterItem, endSale, makePayment

Oct 3, Ron McFadyen13 makeNewSale enterItem endSale makePayment Part of Figure 9.1 System Operations

Oct 3, Ron McFadyen14 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, Store, Cashier Choose, or invent, an object in the application layer for this.

Oct 3, Ron McFadyen15 F Other choices are Store and Cashier F Register was chosen over store as it is conceptually closer to the system event F Register was chosen over Cashier as it is really an actor the runs the Register F Thus Register is the logical choice

Oct 3, Ron McFadyen16 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

Oct 3, Ron McFadyen17 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

Oct 3, Ron McFadyen18 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

Oct 3, Ron McFadyen19 F Every business system should have a controller F A controller is class whose job it is to coordinate the system events F The controller sees to it the messages are sent to the correct objects in the model – it delegates F The reason to have a controller is to separate the business model from the visual logic called a view F This is often called a MVC (Model View Controller) separation

Oct 3, Ron McFadyen20 F Advantage - is that the changes to the model do not affect the GUI (view) logic F Advantage - is that the changes to the GUI (view) do not affect the model logic – could have multiple GUIs – GUI is replaceable F It provides a buffer between the visual (view) and the business logic (model)

Oct 3, Ron McFadyen21 Figure desirable coupling of interface layer to domain layer