1

LECTURE 11
GRASP: Designing Objects with Responsibilities.

Muhammad Zeeshan Sabir

 2

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.”

Muhammad Zeeshan Sabir

 3

THE CRITICAL TOOL

• Not UML
• A mind well educated in design principles

Muhammad Zeeshan Sabir

 4

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

Muhammad Zeeshan Sabir

 5

“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

Muhammad Zeeshan Sabir

 6

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

Muhammad Zeeshan Sabir

 7

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

Muhammad Zeeshan Sabir

 8

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

Muhammad Zeeshan Sabir

 9

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

Muhammad Zeeshan Sabir

 10

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.

Muhammad Zeeshan Sabir

 11

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

Muhammad Zeeshan Sabir

 12

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

Muhammad Zeeshan Sabir

 13

GANG OF FOUR
• Initial 23 design patterns.

Muhammad Zeeshan Sabir

 14

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

Muhammad Zeeshan Sabir

 15

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

Muhammad Zeeshan Sabir

 16

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

Muhammad Zeeshan Sabir

 17

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

Muhammad Zeeshan Sabir

 18

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)

Muhammad Zeeshan Sabir

 19

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

Muhammad Zeeshan Sabir

 20

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

Muhammad Zeeshan Sabir

 21

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

Muhammad Zeeshan Sabir

 22

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.

Muhammad Zeeshan Sabir

 23

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

Muhammad Zeeshan Sabir

 24

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

Muhammad Zeeshan Sabir

 25

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

Muhammad Zeeshan Sabir

 26

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

Muhammad Zeeshan Sabir

 27

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

Muhammad Zeeshan Sabir

 28

CONTROLLER
• The UI layer gets data and an “Enter Item” message (or
some other message, in the case of the assignment)

Muhammad Zeeshan Sabir

 29

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

Muhammad Zeeshan Sabir

 30

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.

Muhammad Zeeshan Sabir

 31

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

Muhammad Zeeshan Sabir

 32

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

Muhammad Zeeshan Sabir

 33

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

Muhammad Zeeshan Sabir

 34

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

Muhammad Zeeshan Sabir