Final grasp ASE
Transcript of Final grasp ASE
•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 . . .. . .