GRASP (General Responsibility Assignment Software Patterns) is a set of principles for assigning responsibilities to classes and objects in software design. It describes nine patterns including creator, informational expert, controller, low coupling, high cohesion, and polymorphism. The patterns provide guidelines for assigning responsibilities to classes to achieve benefits like high cohesion, low coupling, and flexibility to changes. For example, the informational expert pattern suggests assigning a responsibility to the class that has the necessary information to fulfill it.

1. GRASP
General Responsibility Assignment Software Patterns
author: Yuriy Shapovalov (Yurii_Shapovalov@epam.com)

2. Where it came from?
• GRASP like a term and principles firstly was described at Craig
Larman’s book “Applying UML and Patterns”
GRASP stands for:
• General
• Responsibility
• Assignment
• Software
• Patterns (Principles)

3. Nine Patterns
• Creator
• Informational Expert
• Controller
• Low Coupling
• High Cohesion
• Polymorphism
• Pure Fabrication
• Indirection
• Protected Variation

4. Differences from GoF and SOLID
• Patterns of assigning responsibilities (RDD)
• GRASP declares more common principles responsibility
separation, when GoF describe more specific and complex
design patterns.
• SOLID – more common OOP principles less oriented on
responsibility segregation
• GRASP somewhere between GoF patterns and SOLID principles.

5. Representation in Sequence Diagram (UML)
• Relationship between methods and responsibilities.
• Assuming that Sale objects are responsible to create Payment
objects
:Sale
makePayment(cashTendered)
create(cashTendered)
Confidential
:Payment
5

6. Responsibility-Driven Design
• “doing” responsibilities
– Doing something itself, such as creation an object or doing a
calculation.
– Initiating action in other objects
– Controlling and coordinating activities in other objects.
• “knowing” responsibilities
– Knowing about encapsulated data.
– Knowing about related objects.
– Knowing about things it can derive or calculate.

7. Informational Expert
Problem: Which class possesses information about object A?
More common question: What is a general principle of assigning
responsibilities to objects?
Assign the responsibility to the class that knows the necessary
information for performing required action and fulfill the
responsibility.

8. Informational Expert
Tell, Don’t Ask.
“Procedural code gets information then, makes decisions. Objectoriented code tells object to do things” © Alec Sharp

9. Informational Expert
A
B
C
D
GetDataX()
GetDataY()
GetDataZ()
return Z
return Y
return X
DO

10. Informational Expert
A
B
C
D
DoAction()
DoAction(X)
DoAction(Y)
DO

11. Creator
Problem: Who should be responsible for creating object A?
In general, a class B should be responsible for creating instances of
class A if one, or preferably more, of the following apply:
• Instances of B contain or compositely aggregate instances of A
• Instances of B record instances of A
• Instances of B closely use instances of A
• Instances of B have the initializing information for instances of A
and pass it on creation.

12. Creator
• The goal is to define creator-object, which will be related to all
created objects.
64
Board
create
Square
Board
create
Square

13. Creator
In case of complex creation login, based on some external
cases, make sense to use Factory pattern, and delegate creation
responsibility to auxiliary class.
• Related patterns: Concrete Factory and Abstract Factory

14. Low Coupling
• Problem: How to reduce design change impact, support low
dependency and increase reuse?
Coupling is the degree, defines how tightly one component linked
to other components, or how much information it knows about
other components.
• A change in one module usually forces a ripple effect of changes in other
modules.
• Assembly of modules might require more effort and/or time due to the
increased inter-module dependency.
• A particular module might be harder to reuse and/or test because
dependent modules must be included.

15. Tightly Coupled Application
Confidential
15

16. Low Coupling
• Assign a responsibility so that coupling remains low.
Low Coupling is an evaluative pattern, which dictates how to
assign responsibilities to support:
• lower dependency between the classes,
• change in one class having lower impact on other classes,
• higher reuse potential.
http://en.wikipedia.org/wiki/Coupling_(computer_science)#Module_coupling

17. High Cohesion
• Problem: How to keep objects
focused, understandable, manageable, and support low
coupling?
Cohesion is a measure of how strongly related or focused the
responsibilities of a single module are.
High Cohesion is an evaluative pattern that attempts to keep
objects appropriately focused, manageable and understandable.
Alternatively, low cohesion is a situation in which a given element
has too many unrelated responsibilities (“God Object”)

18. High Cohesion
Cohesion is decreased if:
• The functionalities embedded in a class, accessed through its methods, have
little in common.
• Methods carry out many varied activities, often using coarsely grained or
unrelated sets of data.
Disadvantages of low cohesion (or “weak cohesion”) are:
• Increased difficulty in understanding modules.
• Increased difficulty in maintaining a system, because logical changes in the
domain affect multiple modules, and because changes in one module require
changes in related modules.
• Increased difficulty in reusing a module because most applications won’t
need the random set of operations provided by a module.

19. High Cohesion
A
A
??
DoA()
DoA()
DoB()
DoC()
DoB()
DoC()
??

20. Controller
• Problem: Who should be responsible for handling events and
messages from external actors (UI, …)?
• Assign the responsibility to a class, such as:
– A class that represents the overall system, device, or subsystem.
• Façade Controller Pattern
– A class that represent a use case, whereby performs handling
particular system operation.
• Use Case Controller Pattern
• Generally does not perform operation by itself, but delegate
responsibility to component objects.

21. Polymorphism
• Problem: How to act different depending in object’s class, or
how to design pluggable components?
• In case of class behavior might changes, responsibilities
segregates to different behavior specific classes, using
polymorphic operations for this class.
• Advise: Do not use type checking, but conditional logic for
implementation different variations based on object type.

22. Polymorphism
Square
Player
landedOn
RegularSquare
landedOn
GoSquare
landedOn
OtherSquare
landedOn
• There are (roughly) 3 types a polymorphism:
– Ad hoc Polymorphism
– Parametric Polymorphism
– Subtype Polymorphism

23. Pure Fabrication
• Problem: How to assign responsibilities if applying the
Informational Expert principle decreases cohesion and increases
coupling?
• Assign the responsibility to an artificial class that does not
belongs to the domain model.
• Pure Fabrication is a class that does not reflect any business
domain object, but required only for increase cohesion and
decrease coupling.

24. Indirection
• Problem: How to assign responsibilities in order to avoid direct
coupling between two components, and keep ability for reuse.
• Assign responsibility to intermediate class for providing linking
between objects not linking directly.
• Related design patterns: Adapter, Bridge, Mediator.

25. Protected Variations
• Problem: How to design system and subsystems, that changes in
these components does not affects on other components.
• Identify points of possible variations and instability; create
stable interfaces upon instable components.
• Open-Closed Principle almost equivalent to PV pattern.

26. Protected Variations
• There are 2 types of points:
– Variation point – branching point on existing system or in
requirements. For example we need to support several types of
interfaces for tax payment system
– Evolution point – supposed branching point, which might occur in
future, but does not declared by existing requirements.
• Protected variation pattern applying for both variation and
evolution points.

27. Law of Demeter (not part of GRASP)
Specific case of loose coupling.
• Each unit should have only limited knowledge about other units
• Each unit should only talk to its friend (“don’t talk to strangers”)
A
B
C

28. Law of Demeter (not part of GRASP)
More formally, the Law of Demeter for functions requires that a
method m of an object O may only invoke the methods of the
following kinds of objects:
• O itself
• m's parameters
• Any objects created/instantiated within m
• O's direct component objects
• A global variable, accessible by O, in the scope of m
“Don’t talk to strangers”

29. RDD conflicts with Law of Demeter
• Therefore, sending a message to the result of a previous
message send isn't allowed.
However, "returned values are part of the
client/server contract. There need be no
correlation between the structure of an object
and the object returned by the message.“
Wirfs-Brock, Rebecca; McKean, Alan
(November 2002). Object Design:
Roles, Responsibilities, and Collaborations.

30. Overview
Informational Expert
Assign a responsibility to the class that has the information
needed to fulfill it.
Creator
Assign class B the responsibility to create an instance of
class A if one of these is true (the more the better):
• B "contains" or compositely aggregates A.
• B records A.
• B closely uses A.
• B has the initializing data for A that will be passed to A
when it is crated. Thus B is an Expert with respect to
creating A.
Controller
Assign the responsibility to a class representing one of the
following choices:
• Major subsystem classes
• A use case scenario classes within which the system
event occurs
Low Coupling
Assign a responsibility so that coupling remains low.
High Cohesion
Assign a responsibility so that cohesion remains high.

31. Overview
Polymorphism
The same name operations (methods) in the difference
classes is defined. And assign a responsibility to the class
the class that the behavior is changed.
Pure Fabrication
Define a class for convenience' sake that doesn't express
the concept of the problem area at all.
Indirection
Assign the responsibility to an intermediate object to
mediate between other components or services, so that
they are not directly coupled.
Protected Variations
Assign responsibility to create a stable interface around an
unstable or predictably variable subsystem or component.

32. Questions?
Contacts:
Yuriy Shapovalov ( Yurii_Shapovalov@epam.com )
email:
skype:
twitter:
shapovalov.yuri@gmail.com
shapovalov.yuriy
@YuriyShapovalov