Presented By

Babak Danyal

•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

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

: L i b r a r y

b o r r o w R e s o u r c e ( c a l l N u m )

1 : r : = g e t R e s o u r c e ( c a l l N u m ) : R e s o u r c e: C a t a l o g

C a t a l o g i s a n i n f o r m a t i o n e x p e r t o nf i n d i n g a n d r e t u r n i n g a r e s o u r c e ,b a s e d o n a c a l l n u m b e r . I t l o g i c a l l yc o n t a i n s a l l o f t h e m .

b y E x p e r t

W h a t c l a s s s h o u l d b e r e s p o n s i b l e f o rk n o w i n g a r e s o u r c e , g i v e n a c a l l n u m b e r ?

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.

: C a t a l o g

m a k e B o o k ( t i t l e )

1 : c r e a t e ( t i t l e ): B o o k

b y C r e a t o r

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.

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.

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.

r e c o r d B o r r o w e r ( l i b I D )

: S y s t e m

b o r r o w R e s o u r c e ( c a l l N u m )

p r i n t B o r r o w R e p o r t ( )

L i b r a r i a n

?p r i n t B o r r o w R e p o r t ( ) . . .

?b o r r o w R e s o u r c e ( c a l l N u m ) . . .

?r e c o r d B o r r o w e r ( l i b I D ) . . .

C o n t r a c t :r e c o r d B o r r o w e r. . .P o s t c o n d i t i o n s :. . .

C o n t r a c t :b o r r o w R e s o u r c e. . .P o s t c o n d i t i o n s :. . .

C o n t r a c t :p r i n t B o r r o w R e p o r t. . .P o s t c o n d i t i o n s :. . .

U s e C a s e : B o r r o w R e s o u r c e s

T h i s u s e c a s e b e g i n s . . .. . .