copyright © craig larman. 2000 all rights reserved comp-350 object-oriented analysis and design...

Copyright © Craig Larman. 2000 All Rights Reserved

COMP-350 Object-Oriented Analysis and Design

GRASP: Designing Objects with ResponsibilitiesReference: Larman chapter 17

Copyright © Craig Larman. 2000 All Rights Reserved2

Object Design by Responsibilities “Identify requirements, create a domain model, add

methods to the software classes, define messages to meet requirements…”

Too Simple!– What methods belong where?– How do we assign responsibilities to classes?

Object-oriented design is not about UML. It is primarily about assigning Responsibilities to objects.


Responsibility-Driven Design (RDD) Responsibility- Contract or obligation of a class 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 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

Responsibilities are fulfilled by object methods


Examples of object responsibilities

“A Sale object is responsible for creating SalesLineItem objects”(doing)

“A Sale object is responsible for knowing its total” (knowing)


Responsibilities Responsibilities are an abstraction.

– The responsibility for persistence.Large-grained responsibility.

– The responsibility for the sales tax calculation.More fine-grained responsibility.

They are implemented with methods in objects.– 1 method in 1 object– 5 methods in 1 object– 50 methods across 10 objects


Responsibilities in Interaction Diagrams

When drawing interaction diagrams, you are implicitly assigning Responsibilities to particular objects.


Responsibility-Driven Design:GRASP

GRASP: General Responsibility Assignment Software Patterns (or Principles).

GRASP provides basic principles for assignment of Responsibilities to objects.

Think GRASP when drawing interaction diagrams.


GRASP for Responsibility-Driven Design


Workflow

Copyright © Craig Larman. 2000 All Rights Reserved10 10

GRASP PatternsWhich class, in the general case is responsible? You want to assign a responsibility to a class You want to avoid or minimize additional

dependencies You want to maximise cohesion and minimise

coupling You want to increase reuse and decrease

maintenance You want to maximise understandability …..etc.


Five Fundamental GRASP Patterns1. 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?


1. Creator Problem

– Who (i.e. what class) creates a new instance of a class A

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


Creator: example In Monopoly, who creates the Square object Start point: Look at the Domain Model


Creator: SolutionThe Board object contains Square objects, so it is a good candidate.

This also gives us a clue that the relationship should be a composition:


2. Information Expert (or Expert) Problem

– Who (i.e. what class) should be responsible for knowing about instances of a class A

Solution– Assign a knowing responsibility to the class that has

the information needed to fulfill it


Note

When assigning “knowing” or information responsibilities, first look in the Design model for an appropriate class.

If not found in the design model, then look in the Domain model.

This approach helps in clarifying the Design Model


Information Expert: example What class should know about (e.g. status of)

Square objects?– Alternatively, who should be the receiver of

message getSquare(name) Solution:

– Board knows about all squares, i.e. Board has the information necessary to fulfill this responsibility


3. Low Coupling Problem

– How to reduce the impact of change, to support low dependency, and increase reuse?

Solution– Assign a responsibility so that coupling remains low


Coupling How strongly one element (e.g. class) is connected to,

has knowledge of, or depends on other elements Illustrated as dependency relationship in UML class

diagram


CouplingIn object oriented languages, common form of coupling

from TypeX to TypeY include: TypeX has an attribute that refers to a TypeY instance. 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.

TypeX is a direct or indirect subclass of TypeY. TypeY is an interface, and TypeX implements that

interface.


Low coupling Classes are easier to maintain Easier to reuse Changes are localised


Low Coupling: Example

Who has responsibility to create a payment (and associate with a sale)?

Payment POST Sale


Two possibilities:

:POST p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

1. Post

2. Sale :POST :Sale

:Payment

makePayment() 1: makePayment()

1.1. create()

Low coupling suggests Sale because Sale has to be coupled to Payment anyway (Sale knows its total).


4. Controller Problem

– What object (beyond the UI layer) handles events from external actors

– E.g. startup(), playSongs(), etc? 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.


Controller A Controller is a non-user interface object

responsible for receiving or handling a system event.

A Controller defines the method for the system operation.


Controller: example


Note A common defect in the design of controllers is to

give them too much responsibility 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.


Types of Controllers1. Facade controller2. Use case controller


Façade Controller represents the overall system, device, or a

subsystem. a cover, or facade, over the other layers of the

application provides the main point of service calls from the UI

layer down to other layers. could be an abstraction of the overall physical unit,

such as a Register E.g. a class representing the entire software

system, such as POSSystem, ChessGame


When to use Façade controller when there are not "too many" system events When it is not possible for the user interface (UI) to

redirect system event messages to alternating controllers

E.g. in a message processing system


Use case controllers If a use-case controller is chosen, then there is a

different controller for each use case. Note that this is not a domain object; it is an

artificial construct to support the system 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


When to use Use case controller when placing the responsibilities in a facade

controller leads to designs with low cohesion or high coupling

typically when the facade controller is becoming "bloated" with excessive responsibilities.

A use-case controller is a good choice when there are many system events across different processes

it factors their handling into manageable separate classes

provides a basis for knowing and reasoning about the state of the current scenario in progress.


Controller: Class Activity


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


Bloated Controller Poorly designed, a controller class will have low

cohesion- unfocused and handling too many areas of responsibility; this is called a bloated controller.

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.


Cure to Bloated Controller Add more controllers- system does not have to

have only one. Instead of facade controllers, use use-case controllers.

For example, consider an application with many system events, such as an airline reservation system. It may contain the following controllers:

Design the controller so that it primarily delegates the fulfillment of each system operation responsibility on to other objects.


5. High Cohesion Cohesion is a measure of how strongly related the

responsibilities of a class are A class with low cohesion does many unrelated

things. It is hard to understand, hard to reuse, and hard to maintain

A class with high cohesion has a relatively small number of highly-related methods

It collaborates with other objects Modular design


Example of Good and Bad Cohesion


Cohesion: example Example: for the POS system, when we design for

the makePayment() system operation

Reduces the cohesion of Register.


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.


Wrap-up No ‘magic’ to assigning responsibilities If you don’t have a reason for placing a method in

a class, …it shouldn’t be there!

You should be able to say: ‘I placed method X in class Y based on GRASP Z’

copyright © craig larman. 2000 all rights reserved comp-350 object-oriented analysis and design...

Documents