Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference: Larman chapter 17

Copyright © Craig Larman All Rights Reserved 2 Object Design by Responsibilities n “Identify requirements, create a domain model, add methods to the software classes, define messages to meet requirements…” n Too Simple! – What methods belong where? – How do we assign responsibilities to classes? n Object-oriented design is not about UML. It is primarily about assigning Responsibilities to objects.

Copyright © Craig Larman All Rights Reserved 3 Responsibility-Driven Design (RDD) n Responsibility- Contract or obligation of a class n Two types – What must a class “know”? [knowing responsibility] Know about private encapsulated data Know about related objects Know about things it can derive or calculate n What must a class “do”? [doing responsibility] – Do something itself: e.g. create an object, do a calculation – Initiate action in other objects – Control/coordinate actions in other objects n Responsibilities are fulfilled by object methods

Copyright © Craig Larman All Rights Reserved 4 Examples of object responsibilities n “A Sale object is responsible for creating SalesLineItem objects”(doing) n “A Sale object is responsible for knowing its total” (knowing)

Copyright © Craig Larman All Rights Reserved 5 Responsibilities n Responsibilities are an abstraction. – The responsibility for persistence. Large-grained responsibility. – The responsibility for the sales tax calculation. More fine-grained responsibility. n They are implemented with methods in objects. – 1 method in 1 object – 5 methods in 1 object – 50 methods across 10 objects

Copyright © Craig Larman All Rights Reserved 6 Responsibilities in Interaction Diagrams When drawing interaction diagrams, you are implicitly assigning Responsibilities to particular objects.

Copyright © Craig Larman All Rights Reserved 7 Responsibility-Driven Design: GRASP n GRASP: General Responsibility Assignment Software Patterns (or Principles). n GRASP provides basic principles for assignment of Responsibilities to objects. n Think GRASP when drawing interaction diagrams.

Copyright © Craig Larman All Rights Reserved 8 GRASP for Responsibility-Driven Design

Copyright © Craig Larman All Rights Reserved 9 Workflow

Copyright © Craig Larman All Rights Reserved 10 GRASP Patterns Which class, in the general case is responsible? You want to assign a responsibility to a class n You want to avoid or minimize additional dependencies n You want to maximise cohesion and minimise coupling n You want to increase reuse and decrease maintenance n You want to maximise understandability n …..etc.

Copyright © Craig Larman All Rights Reserved 11 Five Fundamental GRASP Patterns 1. Creator: who should be responsible for creating a specific object? 2. Information Expert: who should be responsible for knowing about a particular object? 3. High Cohesion: how should responsibilities be grouped within classes? 4. Low Coupling: how strongly should elements be tied to others? 5. Controller: who should be the first to receive a message in the domain layer?

Copyright © Craig Larman All Rights Reserved Creator n Problem – Who (i.e. what class) creates a new instance of a class A n Solution – Assign class B the responsibility to create an instance of class A if one of these is true: B “contains” A B records A B closely uses A B has the Initializing data for A

Copyright © Craig Larman All Rights Reserved 13 Creator: example n In Monopoly, who creates the Square object n Start point: Look at the Domain Model

Copyright © Craig Larman All Rights Reserved 14 Creator: Solution The Board object contains Square objects, so it is a good candidate. This also gives us a clue that the relationship should be a composition:

Copyright © Craig Larman All Rights Reserved Information Expert (or Expert) n Problem – Who (i.e. what class) should be responsible for knowing about instances of a class A n Solution – Assign a knowing responsibility to the class that has the information needed to fulfill it

Copyright © Craig Larman All Rights Reserved 16 Note n When assigning “knowing” or information responsibilities, first look in the Design model for an appropriate class. n If not found in the design model, then look in the Domain model. n This approach helps in clarifying the Design Model

Copyright © Craig Larman All Rights Reserved 17 Information Expert: example n What class should know about (e.g. status of) Square objects? – Alternatively, who should be the receiver of message getSquare(name) n Solution: – Board knows about all squares, i.e. Board has the information necessary to fulfill this responsibility

Copyright © Craig Larman All Rights Reserved Low Coupling n Problem – How to reduce the impact of change, to support low dependency, and increase reuse? n Solution – Assign a responsibility so that coupling remains low

Copyright © Craig Larman All Rights Reserved 19 Coupling n How strongly one element (e.g. class) is connected to, has knowledge of, or depends on other elements n Illustrated as dependency relationship in UML class diagram

Copyright © Craig Larman All Rights Reserved 20 Coupling In object oriented languages, common form of coupling from TypeX to TypeY include: n TypeX has an attribute that refers to a TypeY instance. n TypeX has a method which references an instance of TypeY, by any means. These typically include a parameter or local variable of type TypeY, or the object returned from a message being an instance of TypeY. n TypeX is a direct or indirect subclass of TypeY. n TypeY is an interface, and TypeX implements that interface.

Copyright © Craig Larman All Rights Reserved 21 Low coupling n Classes are easier to maintain n Easier to reuse n Changes are localised

Copyright © Craig Larman All Rights Reserved 22 Low Coupling: Example Who has responsibility to create a payment (and associate with a sale)?

Copyright © Craig Larman All Rights Reserved 23 Two possibilities: 1. Post 2. Sale Low coupling suggests Sale because Sale has to be coupled to Payment anyway (Sale knows its total).

Copyright © Craig Larman All Rights Reserved Controller n Problem – What object (beyond the UI layer) handles events from external actors – E.g. startup(), playSongs(), etc? n Solution – Assign the responsibility to an object representing one of these choices A facade controller which represents the overall system, root object, device or subsystem Example: Jukebox A use case controller which which represents a use case scenario within which the system operations occurs Example: makeSaleHandler. makeSaleCoordinator, etc. – These classes often don’t do the work, but delegate it to others.

Copyright © Craig Larman All Rights Reserved 25 Controller n A Controller is a non-user interface object responsible for receiving or handling a system event. n A Controller defines the method for the system operation.

Copyright © Craig Larman All Rights Reserved 26 Controller: example

Copyright © Craig Larman All Rights Reserved 27 Note n A common defect in the design of controllers is to give them too much responsibility n Normally, a controller should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It does not do much work itself.

Copyright © Craig Larman All Rights Reserved 28 Types of Controllers 1. Facade controller 2. Use case controller

Copyright © Craig Larman All Rights Reserved 29 Façade Controller n represents the overall system, device, or a subsystem. n a cover, or facade, over the other layers of the application n provides the main point of service calls from the UI layer down to other layers. n could be an abstraction of the overall physical unit, such as a Register n E.g. a class representing the entire software system, such as POSSystem, ChessGame

Copyright © Craig Larman All Rights Reserved 30 When to use Façade controller n when there are not "too many" system events n When it is not possible for the user interface (UI) to redirect system event messages to alternating controllers n E.g. in a message processing system

Copyright © Craig Larman All Rights Reserved 31 Use case controllers n If a use-case controller is chosen, then there is a different controller for each use case. n Note that this is not a domain object; it is an artificial construct to support the system n For example, if the NextGen POS application contains use cases such as Process Sale and Handle Returns, then there may be a ProcessSaleHandler class and so forth

Copyright © Craig Larman All Rights Reserved 32 When to use Use case controller n when placing the responsibilities in a facade controller leads to designs with low cohesion or high coupling n typically when the facade controller is becoming "bloated" with excessive responsibilities. n A use-case controller is a good choice when there are many system events across different processes n it factors their handling into manageable separate classes n provides a basis for knowing and reasoning about the state of the current scenario in progress.

Copyright © Craig Larman All Rights Reserved 33 Controller: Class Activity

Copyright © Craig Larman All Rights Reserved 34 n By the Controller pattern, here are some choices: 1. Register, POSSystem – represents the overall "system," device, or subsystem – Façade controller 2. ProcessSaleHandler, ProcessSaleSession – represents a receiver or handler of all system events of a use case scenario – Use case controller

Copyright © Craig Larman All Rights Reserved 35

Copyright © Craig Larman All Rights Reserved 36 Bloated Controller n Poorly designed, a controller class will have low cohesion- unfocused and handling too many areas of responsibility; this is called a bloated controller. n Signs of bloating include: – only a single controller class receiving all system events in the system, and there are many of them. – The controller itself performs many of the tasks necessary to fulfill the system event, without delegating the work. – A controller has many attributes, and maintains significant information about the system or domain, which should have been distributed to other objects, or duplicates information found elsewhere.

Copyright © Craig Larman All Rights Reserved 37 Cure to Bloated Controller n Add more controllers- system does not have to have only one. Instead of facade controllers, use use-case controllers. n For example, consider an application with many system events, such as an airline reservation system. It may contain the following controllers: n Design the controller so that it primarily delegates the fulfillment of each system operation responsibility on to other objects.

Copyright © Craig Larman All Rights Reserved High Cohesion n Cohesion is a measure of how strongly related the responsibilities of a class are n A class with low cohesion does many unrelated things. It is hard to understand, hard to reuse, and hard to maintain n A class with high cohesion has a relatively small number of highly-related methods n It collaborates with other objects n Modular design

Copyright © Craig Larman All Rights Reserved 39 Example of Good and Bad Cohesion

Copyright © Craig Larman All Rights Reserved 40 Cohesion: example n Example: for the POS system, when we design for the makePayment() system operation Reduces the cohesion of Register.

Copyright © Craig Larman All Rights Reserved 41 n By delegating Payment creation to Sale, we not only decrease coupling, but we also increase the cohesion of Register. Since Register has fewer responsibilities, it is more cohesive.

Copyright © Craig Larman All Rights Reserved 42 Wrap-up n No ‘magic’ to assigning responsibilities n If you don’t have a reason for placing a method in a class, …it shouldn’t be there! n You should be able to say: ‘I placed method X in class Y based on GRASP Z’