2. •Larman introduces a set of basic patterns that he calls
GRASP: General Responsibility Assignment Software
Pattern
•Five GRASP Patterns:
–Information Expert
–Creator
–High Cohesion
–Low Coupling
–Controller
3. Problem:A system will have hundreds of classes. How do I
begin to assign responsibilities to them?
Solution:Assign responsibility to the Information Expert–the
class that has the information necessary to fulfill the
responsibility.
Mechanics:
Step 1: Clearly state the responsibility
Step 2: Look for classes that have the information we need to
fulfill the responsibility.
Step 3:Domain Model or Design Model?
Step 4:Sketch out some interaction diagrams.
Step 5:Update the class diagram.
4. :L ib r a r y
b o r r o w R e s o u r c e (c a llN u m )
1 : r := g e tR e s o u r c e (c a llN u m ): R e s o u r c e
:C a ta lo g
C a ta lo g is a n in fo r m a tio n e x p e r t o n
fin d in g a n d r e tu r n in g a r e s o u r c e ,
b a s e d o n a c a ll n u m b e r . It lo g ic a lly
c o n ta in s a ll o f th e m .
b y E x p e r t
W h a t c la s s s h o u ld b e r e s p o n s ib le fo r
k n o w in g a r e s o u r c e , g iv e n a c a ll n u m b e r ?
5. Problem:
Who creates new instances of some class?
Solution:
Let class A create an instance of class B if….
•A aggregates(whole-part relationship) B objects
•A contains B objects
•A records instances of B objects
•A closely uses B objects
•A has initialization data that is needed when creating B
objects.
Mechanics:
Step 1: Look at Domain / Design model and ask: “Who should
be creating these classes”?
Step 2:Look for classes that create, aggregate, etc.
Step 3:Sketch or update interaction / class diagrams.
6. :C a ta lo g
m a k e B o o k (title )
1 : c re a te (title )
:B o o k
b y C r e a to r
7. Problem:
How do you support low dependency, low change impact, and
increased reuse.
Solution:
Assign responsibility so responsibility remains low.
Mechanics:
Look for classes with many associations to other classes.
Look for a methods that rely on a lot of other methods (or methods in
other classes, I.e. dependencies.
Rework your design as needed.
8. Problem:
How do you keep complexity manageable?
Solution:
Assign responsibility so that cohesion remains high.
Mechanics:
Look for classes with too-few or disconnected methods.
Look for methods that do to much (hint: method name)
Rework your design as needed.
9. Problem:
Who handles events from external actors, e.g. startup(),
playSongs(), etc?
Solution:
Assign the responsibility to a controller class, such as:
•A class that represents the overall system, device, or
subsystem. Example: Jukebox.
•A class that represents a use case. Example: makeSaleHandler.
makeSaleCoordinator, etc.
•These classes often don’t do the work, but delegate it to
others.
10. re c o rd B o rro w e r(lib ID )
:S y s te m
b o rro w R e s o u rc e (c a llN u m )
p rin tB o rro w R e p o rt()
L ib ra ria n
?
p rin tB o rro w R e p o rt() . . .
?
b o rro w R e s o u rc e (c a llN u m ) . . .
?
re c o rd B o rro w e r(lib ID ) . . .
C o n tra c t:
re c o rd B o rro w e r
...
P o s tc o n d itio n s :
...
C o n tra c t:
b o rro w R e s o u rc e
...
P o s tc o n d itio n s :
...
C o n tra c t:
p rin tB o rro w R e p o rt
...
P o s tc o n d itio n s :
...
U s e C a s e : B o rro w R e s o u rc e s
T h is u s e c a s e b e g in s ...
...
