GRASP Design Principles

By Danya Rao

GRASP

stands for General Responsibility Assignment Software Patterns guides in assigning responsibilities to collaborating objects. 9 GRASP patterns Creator nformation !"pert #ow Coupling Controller $ig% Co%esion ndirection Polymorp%ism Protected &ariations Pure 'abrication

Responsibility(

Responsibility can be(

accomplis%ed by a single object. or a group of object collaborati)ely accomplis% a responsibility.

GRASP %elps us in deciding w%ic% responsibility s%ould be assigned to w%ic% object*class. dentify t%e objects and responsibilities from t%e problem domain+ and also identify %ow objects interact wit% eac% ot%er. Define blue print for t%ose objects , i.e. class wit% met%ods implementing t%ose responsibilities.

Creator

-%o creates an .bject/ .r w%o s%ould create a new instance of some class/ 0Container1 object creates 0contained1 objects. Decide w%o can be creator based on t%e objects association and t%eir interaction.

!"ample for Creator

Consider &ideoStore and &ideo in t%at store. &ideoStore %as an aggregation association wit% &ideo. .e+ &ideoStore is t%e container and t%e &ideo is t%e contained object. So+ we can instantiate )ideo object in &ideoStore class

!"ample diagram

!"ample for creator

!"pert

Gi)en an object o+ w%ic% responsibilities can be assigned to o/ !"pert principle says , assign t%ose responsibilities to o for w%ic% o %as t%e information to fulfill t%at responsibility. 2%ey %a)e all t%e information needed to perform operations+ or in some cases t%ey collaborate wit% ot%ers to fulfill t%eir responsibilities.

!"ample for !"pert

Assume we need to get all t%e )ideos of a &ideoStore. Since &ideoStore 3nows about all t%e )ideos+ we can assign t%is responsibility of gi)ing all t%e )ideos can be assigned to &ideoStore class. &ideoStore is t%e information e"pert.

!"ample for !"pert

!"ample for !"pert

#ow Coupling

$ow strongly t%e objects are connected to eac% ot%er/ Coupling , object depending on ot%er object. -%en depended upon element c%anges+ it affects t%e dependant also. #ow Coupling , $ow can we reduce t%e impact of c%ange in depended upon elements on dependant elements. Prefer low coupling , assign responsibilities so t%at coupling remain low. 4inimi5es t%e dependency %ence ma3ing system maintainable+ efficient and code reusable

#ow coupling

2wo elements are coupled+ if

.ne element %as aggregation*composition association wit% anot%er element. .ne element implements*e"tends ot%er element.

!"ample for poor coupling

%ere class Rent 3nows about bot% &ideoStore and &ideo objects. Rent is depending on bot% t%e classes.

!"ample for low coupling

&ideoStore and &ideo class are coupled+ and Rent is coupled wit% &ideoStore. 2%us pro)iding low coupling.

Controller

Deals wit% %ow to delegate t%e re6uest from t%e 7 layer objects to domain layer objects. w%en a re6uest comes from 7 layer object+ Controller pattern %elps us in determining w%at is t%at first object t%at recei)e t%e message from t%e 7 layer objects. 2%is object is called controller object w%ic% recei)es re6uest from 7 layer object and t%en controls*coordinates wit% ot%er object of t%e domain layer to fulfill t%e re6uest. t delegates t%e wor3 to ot%er class and coordinates t%e o)erall acti)ity.

Controller

-e can ma3e an object as Controller+ if

.bject represents t%e o)erall system 8facade controller9 .bject represent a use case+ %andling a se6uence of operations 8session controller9. can reuse t%is controller class. Can use to maintain t%e state of t%e use case. Can control t%e se6uence of t%e acti)ities

Benefits

!"ample for Controller

Bloated Controllers

Controller class is called bloated+ if

2%e class is o)erloaded wit% too many responsibilities. Solution , Add more controllers Controller class also performing many tas3s instead of delegating to ot%er class. Solution , controller class %as to delegate t%ings to ot%ers.

$ig% Co%esion

$ow are t%e operations of any element are functionally related/ Related responsibilities in to one manageable unit. Prefer %ig% co%esion Clearly defines t%e purpose of t%e element Benefits

!asily understandable and maintainable. Code reuse #ow coupling

!"ample for low co%esion

!"ample for $ig% Co%esion

Polymorp%ism

$ow to %andle related but )arying elements based on element type/ Polymorp%ism guides us in deciding w%ic% object is responsible for %andling t%ose )arying elements. Benefits( %andling new )ariations will become easy.

!"ample for Polymorp%ism

t%e getArea89 )aries by t%e type of s%ape+ so we assign t%at responsibility to t%e subclasses.

By sending message to t%e S%ape object+ a call will be made to t%e corresponding sub class object , Circle or 2riangle.

Pure 'abrication

'abricated class* artificial class , assign set of related responsibilities t%at doesn:t represent any domain object. Pro)ides a %ig%ly co%esi)e set of acti)ities. Be%a)ioral decomposed , implements some algorit%m. !"amples( Adapter+ Strategy Benefits( $ig% co%esion+ low coupling and can reuse t%is class.

!"ample

Suppose we S%ape class+ if we must store t%e s%ape data in a database. f we put t%is responsibility in S%ape class+ t%ere will be many database related operations t%us ma3ing S%ape inco%esi)e. So+ create a fabricated class DBStore w%ic% is responsible to perform all database operations. Similarly log nterface w%ic% is responsible for logging information is also a good e"ample for Pure 'abrication.

ndirection

$ow can we a)oid a direct coupling between two or more elements. ndirection introduces an intermediate unit to communicate between t%e ot%er units+ so t%at t%e ot%er units are not directly coupled. Benefits( low coupling !"ample( Adapter+ 'acade+ .bsere)er

!"ample for ndirection

$ere polymorp%ism illustrates indirection Class !mployee pro)ides a le)el of indirection to ot%er units of t%e system.

Protected &ariation

$ow to a)oid impact of )ariations of some elements on t%e ot%er elements. t pro)ides a well defined interface so t%at t%e t%ere will be no affect on ot%er units. Pro)ides fle"ibility and protection from )ariations. Pro)ides more structured design. !"ample( polymorp%ism+ data encapsulation+ interfaces

Reference

Applying 74# and Patterns+ 2%ird !dition+ Craig #arman