Chapter 17

GRASP: Designing Objects with

Responsibilities.

CS6359 Fall 2011 John Cole 1

 What’s Next
• “After identifying your requirements and
creating a domain model, add methods to the
appropriate classes and define the messaging
between the objects to fulfill the
requirements.”

CS6359 Fall 2011 John Cole 2

 The Critical Tool
• Not UML
• A mind well educated in design principles

CS6359 Fall 2011 John Cole 3

 Object Design
• What has been done? Prior activities
• How do things relate?
• How much design modeling to do, and how?
• What is the output?

CS6359 Fall 2011 John Cole 4

 “Process” Inputs
• Use Cases—the most architecturally
significant, high business value
• Programming experiments to find show-
stopper technical problems
• Use case text defines visible behavior that
objects must support
• Sequence diagrams
• Operation contracts
CS6359 Fall 2011 John Cole 5
 Activities
• Start coding, with test-first development
• Start some UML modeling for object design
• Or start with another modeling technique
such as CRC cards
• Models are to understand and communicate,
not to document

CS6359 Fall 2011 John Cole 6

 Outputs
• UML interaction, class, and package diagrams
• UI sketches and prototypes
• Database models
• Report sketches and prototypes

CS6359 Fall 2011 John Cole 7

 Responsibilities
• Responsibilities, Roles, and Collaboration
• Responsibility-driven design
• Doing responsibilities
• Knowing responsibilities
• Low representational gap

CS6359 Fall 2011 John Cole 8

 GRASP
• General Responsibility Assignment Software
Pattern
• A learning aid for OO design with
responsibilities

CS6359 Fall 2011 John Cole 9

 Responsibilities, GRASP, UML
• Assign responsibilities to objects while coding
or drawing interaction diagrams.
• Diagram on p. 278: Sale objects create
payments, invoked with a makePayment
message.

CS6359 Fall 2011 John Cole 10

 Patterns
• General principles and idiomatic solutions for
creating software
• If codified in a format describing the problem
and solution, these become patterns
• For example: Information Expert
• Problem: what is the basic principle by which
to assign responsibilities to objects?
• Solution: assign to a class that has the
information to fulfill it
CS6359 Fall 2011 John Cole 11
 Pattern Names
• Names give us a way to deal with larger-scale
things rather than describing them
• Facilitates communication
• No “new patterns” Pattern means repetition
• GRASP codifies and names existing patterns

CS6359 Fall 2011 John Cole 12

 Gang of Four
• Initial 23 design patterns.

CS6359 Fall 2011 John Cole 13

 GRASP Patterns
• Creator
• Information Expert
• Low Coupling
• Controller
• High Cohesion

CS6359 Fall 2011 John Cole 14

 Creator Pattern
• Who creates a particular object?
• In Monopoly, who creates the Square object?
• Obviously, the Board object. Not the dice, not
the chance cards, but the Board.
• So, in general, containers create the things
contained

CS6359 Fall 2011 John Cole 15

 Creator
• Problem: Who creates A?
• Solution: assign class B the responsibility to
create an instance of A if one or more are
true:
– B contains or aggregates A
– B records A
– B closely uses A
– B has the initializing data for A

CS6359 Fall 2011 John Cole 16

 Creator
• A composite object is usually a good choice for
creating its parts
• If a class has the initialization data for an
object, this is the Expert pattern

CS6359 Fall 2011 John Cole 17

 Creator--Contraindications
• When not to use:
– When creating requires complexity, such as using
existing instances of a class, conditionally creating
an instance from one class or another based upon
some external property, etc.
– In these cases, delegate creation to a helper class
called a Concrete Factory or Abstract Factory
(p.440)

CS6359 Fall 2011 John Cole 18

 Expert
• This is the class that has the information
necessary to fulfill some responsibility.
• If there are relevant classes in the design
model, look there first.
• If not, look at the domain model

CS6359 Fall 2011 John Cole 19

 Expert
• For example, in NextGen, some class needs to
know the grand total of a sale. Who?
• To determine the grand total, we need all
SalesLineItem instances.
• Sale has these, so it is the logical choice
• SalesLineItem can determine the subtotal for
each line item, so it is the Expert there
• ProductDescription knows the prices
CS6359 Fall 2011 John Cole 20
 Expert-- Contraindications
• When there are problems with coupling or
cohesion
• For example, Sale has all the sale data, so you
could logically think it would store that in the
database. However, that makes Sale
dependent upon database (third layer) logic

CS6359 Fall 2011 John Cole 21

 Low Coupling
• Coupling is a measure of how strongly one
element is connected to, has knowledge of, or
relies upon other elements
• An element with Low Coupling is not
dependent upon too many other elements.
But how many is too many?
• High coupling is not really the problem; it is
high coupling to potentially unstable (likely to
be changed) objects.
CS6359 Fall 2011 John Cole 22
 Low Coupling
• Problems with high coupling:
– Forced local changes because of changes in
related classes
– Harder to understand in isolation
– Harder to reuse because it requires other classes
• Assign responsibility so coupling remains low
• This reduces the impact of change

CS6359 Fall 2011 John Cole 23

 NextGen example
• If we need to create a Payment instance and
associate it with Sale, who should do it? Since
Register records a payment, the Creator
pattern suggests it
• On the other hand, Sale could create Payment
and that would not increase the coupling
• In practice, level of coupling alone is not
sufficient

CS6359 Fall 2011 John Cole 24

 Forms of Coupling
• X has an attribute of type Y
• A type X object calls on services in Y
• X has a method that references an instance of
Y
• X is a direct or indirect subclass of Y
• Y is an interface that X implements

CS6359 Fall 2011 John Cole 25

 Controller
• This is an object just below the UI layer that
coordinates a system’s operation
• For example, the “End Sale” button in a POS
system or the “Spell Check” button on a word
processor.
• This is a delegation pattern

CS6359 Fall 2011 John Cole 26

 Controller
• Assign responsibility to a class with one of the
following:
– Represents the overall “system,” a “root object,” a
device the software is running within, or a major
subsystem (façade controller)
– Represents a use case scenario within which the
system event occurs, often called
<UseCaseName>Handler
• Window, View, and Document are not on the
list
CS6359 Fall 2011 John Cole 27
 Controller
• The UI layer gets data and an “Enter Item”
message (or some other message, in the case
of the assignment)

CS6359 Fall 2011 John Cole 28

 Controller
• You may want to use the same controller class
for all system events of one use case so it can
maintain state.
• Possible problem of over-assignment of
responsibility
• It should delegate the work to other objects,
not do it

CS6359 Fall 2011 John Cole 29

 Façade Controller
• Suitable when there are not too many system
events
• This could be an abstraction of the overall
physical unit, such as PhoneSwitch,
CashRegister, etc.

CS6359 Fall 2011 John Cole 30

 Use Case Controller
• When using a façade controller leads to low
cohesion and high coupling
• When the code in façade controller gets too
big

CS6359 Fall 2011 John Cole 31

 Bloated Controller
• There is only one and it handles too many
events
• The controller performs the work rather than
delegating it
• Controller has many attributes and maintains
significant system or domain info

CS6359 Fall 2011 John Cole 32

 High Cohesion
• Cohesion is a measure of how strongly related
the responsibilities of an element are
• A class with low cohesion does many
unrelated things. It is hard to understand,
hard to reuse, hard to maintain, and delicate
• In the POS system, if Register creates the
payment, this is less cohesive than if Sale does
it

CS6359 Fall 2011 John Cole 33

 High Cohesion
• A class with high cohesion has a relatively
small number of highly-related methods
• It collaborates with other objects
• Modular design

CS6359 Fall 2011 John Cole 34