1

GRASP : Designing Objects with Responsibilities

Larman chapter 16

2

Object design

• Can be described as……

After identifying your requirements and creating a domain model, then add methods to the software classes, and define the messaging between the objects to fulfill the requirements.

3

GRASP patterns

• General Responsibility Assignment Software Patterns

– A learning aid to help one understand essential object design

– Assigment of responsibilities occurs during creation of interaction diagrams and certainly during programming.

4

Responsibilities

• Related to the obligations of an object

• Types :– Knowing

• About private encapsulated data

• About related objects• About things it can derive

or calculate– Doing

• Doing something itself• Initiating a action in other

objects• Controlling activities in

other objects

: Sale

makePay ment(cashTendered)

: Pay mentcreate(cashTendered)

implies Sale objects hav e aresponsibility to create Pay ments

–Responsibilities are implemented using methods

5

Patterns

• A named description of a problem and solution that can be applied to a new context.

• Patterns : – attempt to codify tried-and-true knowledge and principles.– facilitates communication.

• GRASP patterns : • Information Expert• Creator• High Cohesion• Low coupling• Controller

6

Name : Controller

• Solution : – Assign the responsibility for receiving or handling a system event

message to a class representing one of the following choices :

• Represent the overall system, device or subsystem (Façade controller)

• Represent a use case scenario within which the system events occur. Often named <UseCaseName>Handler or <UseCaseName>Session

– Use the same controller for all system events in the sme use case scenario

• Problem : – Who should be responsible for handling an input system event ?

7

Example of Controller pattern

• Who should be the controller for system events ?

Which class of object should be responsible f or receiv ing thissy stem ev ent message?

It is sometimes called the controller or coordinator. It does notnormally do the work, but delegates it to other objects.

The controller is a kind of "f acade" onto the domain lay er f romthe interf ace lay er.

actionPerf ormed( actionEv ent )

: ???

: Cashier

:SaleJFrame

presses button

enterItem(itemID, qty )

InterfaceLayer

DomainLayer

sy stem ev ent message

The Controller pattern suggest :

•A Facade controller

•Register

•POSSystem

•A receiver or handler of all system events of a use case scanario

•ProssSaleHandler

•ProcessSaleSession

8

Facade Controller

actionPerf ormed( actionEv ent )

:Register

: Cashier

:SaleJFrame

presses button

1: enterItem(itemID, qty )

:Sale1.1: makeLineItem(itemID, qty )

Interface Layer

Domain Layer

sy stem ev ent message

controller

9

System events and Allocating system operations

Register

...

endSale()enterItem()makeNewSale()makePay ment()

makeNewReturn()enterReturnItem(). . .

Sy stem

endSale()enterItem()makeNewSale()makePay ment()

makeNewReturn()enterReturnItem(). . .

sy stem operationsdiscov ered during sy stembehav ior analy sis

allocation of sy stemoperations during design,using one f acade controller

ProcessSaleHandler

...

endSale()enterItem()makeNewSale()makePay ment()

Sy stem

endSale()enterItem()makeNewSale()makePay ment()

enterReturnItem()makeNewReturn(). . .

allocation of sy stemoperations during design,using sev eral use casecontrollers

HandleReturnsHandler

...

enterReturnItem()makeNewReturn(). . .

enterItem(itemID, quantity )

:Sy stem: Cashier

endSale()

makePay ment(amount)

Process Sale Scenario

description, total

total with taxes

change due, receipt

* [more items]

makeNewSale()

System Sequence Diagram

10

Name : Information Expert

• Solution :– Assign a responsibility to the information

expert- the class that has the information necessary to fullfill the responsibility.

• Problem :– What is a general principle of assigning

responsibilities to objects.

11

Example of Information Expert

Sale

datetime

SalesLineItem

quantity

ProductSpecif ication

descriptionpriceitemID

Described-by*

Contains

1..*

1

1Sale

datetime

getTotal()

SalesLineItem

quantity

getSubtotal()

ProductSpecif ication

descriptionpriceitemID

getPrice()New method

:ProductSpecif ication

1.1: p := getPrice()

1 *: st := getSubtotal(): Salet := getTotal()

*:SalesLineItem

:SalesLineItem

Who should be responsible for knowing the grand total of a sale ?

12

Name : Creator

• Solution : – Class B has the responsibility to create an instance of

class A if : – B aggregates A objects– B contains A objects– B closely uses A objects– B has the initializing data.

B is a creator of A objects.

• Problem : – Who should be responsible for creating a new

instance of some class ?

13

Example of Creator

• Who should be responsible for creating a SalesLineItem ?

Sale

datetime

SalesLineItem

quantity

ProductSpecif ication

descriptionpriceitemID

Described-by*

Contains

1..*

1

1: Register : Sale

makeLineItem(quantity )

: SalesLineItemcreate(quantity )

14

Name : Low Coupling

• Solution :– Assign a responsibility so that coupling

remains low.

• Problem :– How to support low dependency, low change

impact, and increased reuse ?

Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.

15

Example of Low Coupling

• Who should be responsible for creating a Payment instance and associate with a Sale ?

: Register p : Pay ment

:Sale

makePay ment() 1: create()

2: addPay ment(p)

: Register :Sale

:Pay ment

makePay ment() 1: makePay ment()

1.1. create()

Bad Coupling

Good Coupling

Here are two patterns – Low Coupling and Creator – that suggests different solutions.

Low Coupling is an evaluative principle.

16

Name : High Cohesion

• Solution :– Assign a responsibility so that cohesion

remains high.

• Problem :– How to keep complexity manageable ?

Cohesion is a measure of how strongly related and focused the responsibilities of an element are.

17

Example of High Cohesion

• Who should be responsible for creating a Payment instance and associate it with a Sale ?

: Register : Sale

addPay ment( p )

p : Pay mentcreate()

makePay ment()

: Register : Sale

makePay ment()

: Pay mentcreate()

makePay ment()

Ex.1

Ex.2

Creator pattern suggest ex. 1

High Cohesion pattern suggest ex. 2