Submitted i by i: i Sadaf i Jabeen

i i i

Roll i no i: i BO461208
i i

Course: i iDesign iPatterns

i

Course i Code i: i 3481

i i

Semester i: iSpring, i2021

Submitted i to i: i Sr. iKashif iBhatti
i i

Assignment i no. i 1 i i

1
 ALLAMA iIQBAL iOPEN iUNIVERSITY iISLAMABAD
(Department iof iComputer iScience)

Assignment iNo. i1
(Units: i i1-4)

Question ino.1
Q. i1. (a) What iis imeant iby ithe iterm i“Design iPattern”? iHow idesign iPatterns isolve
idesign iProblems. iExplain ithe iconcept iin idetail iwith ithe ihelp iof iproper
iexamples.
Answer:

Design iPattern:

A idesign ipattern iprovides ia igeneral ireusable isolution ifor ithe icommon iproblems ithat ioccur
iin isoftware idesign. iThe ipattern itypically ishows irelationships iand i interactions ibetween
iclasses ior iobjects. iThe iidea iis ito ispeed iup ithe idevelopment iprocess iby iproviding iwell
itested, iproven idevelopment/design iparadigm.

In i1994, ifour iauthors iErich iGamma, iRichard iHelm, iRalph iJohnson iand iJohn iVlissides
ipublished ia ibook ititled iDesign iPatterns i- iElements iof iReusable iObject-Oriented iSoftware
iwhich iinitiated ithe iconcept iof iDesign iPattern iin iSoftware idevelopment.

These iauthors iare icollectively iknown ias iGang iof iFour i(GOF). iAccording ito ithese iauthors
idesign ipatterns iare iprimarily ibased ion ithe ifollowing iprinciples iof iobject iorientated idesign.

 Program ito ian iinterface inot ian iimplementation

 Favor iobject icomposition iover iinheritance

How idesign ipatterns isolve idesign iproblems:

Design ipatterns iare iprogramming ilanguage i independent istrategies ifor isolving ia icommon
iproblem. iThat imeans ia idesign ipattern irepresents ian iidea, inot ia iparticular iimplementation.
iBy iusing ithe idesign ipatterns, iyou ican imake i your icode imore iflexible, ireusable, iand
imaintainable.

It’s inot imandatory ito iimplement idesign ipatterns i in i your iproject ialways. iDesign ipatterns iare
inot i meant ifor iproject idevelopment. iDesign ipatterns iare imeant ifor icommon iproblem-
solving. iWhenever ithere iis ia ineed, iyou ihave ito iimplement ia isuitable ipattern ito iavoid isuch
2
iproblems i in ithe ifuture. iTo ifind iout iwhich ipattern ito iuse. iYou ijust ihave ito itry ito
iunderstand ithe idesign ipatterns iand itheir ipurposes. iOnly iby ithen, i you iwill ibe iable ito ipick
ithe iright ione.

Example: i

For iexample, iin imany ireal-world isituations, iwe iwant ito icreate ionly ione i instance iof ia iclass.
iFor iexample, ithere ican ibe ionly ione iactive ipresident iof ithe icountry iat ia itime iregardless iof
ipersonal i identity. iThis ipattern iis icalled ia iSingleton ipattern. iOther isoftware iexamples icould
ibe ia isingle iDB iconnection ishared iby i multiple iobjects ias icreating ia iseparate iDB iconnection
ifor ievery iobject iwill ibe icostly. iSimilarly, ithere ican ibe ia isingle iconfiguration i manager ior
ierror imanager i in ian iapplication ithat ihandles iall iproblems i instead iof icreating i multiple
imanagers. i

(b) How iare idesign ipatterns idifferent ifrom iAlgorithms iand iData
iStructure? iExplain iit iwith ithe ihelp iof isuitable iexample.
Answer: i

Difference iof iDesign iPatterns ifrom iAlgorithms i& iData iStructure:

All iof ithree iof ithese ibasically icompile ito ithis: iknowledge iof iefficient icode iplacement iand
iefficient iexecution iof icode ito iachieve ithe ibest ipossible iresult iin ithe ishortest iamount iof itime.
iWhat ia imouthful. iOf icourse, ithat’s inot ithe iofficial idefinition ibut ithat’s itotally ifine. iAn
ialgorithm, ithen, iis ibasically ia istep-by-step iprocedure ifor icalculations/execution. iData
istructure iis ia iparticular iway iof istoring iand iorganizing idata i(efficiently). iA idesign ipattern iis
ibasically ia isolution ito ia ispecific idesign iproblem. iDesign inot imeaning igraphic idesign, ibut
irather icode istructure iand isetup.
Well, ithe ibiggest ideal iwith ithese ithings iis iefficiency. iHow iwill ithese ihelp iyou ibecome imore
iefficient iwith iyour icoding? iComputer iprograms iare ibasically ialgorithms istrung itogether
icoupled iwith idata istorage.
I iwould isay ithat ia idesign ipattern idefines istructure, iwhereas ian ialgorithm idefines ibehavior.

Design iPattern i i i i i i i i i i i i i i i i i i i i i i i i i i i| i i i iAlgorithm

-------------------------------------------------------------
Abstract i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i| iConcrete
Control iStructure i i i i i i i i i i i i i i i i i i i i i i i i i| iSet iof iActions i i i i
Template i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i| iImplementation
Flexible i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i| iDeterministic
Blueprint i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i| iRecipe
3
Example:
I iwas isearching ifor i"Undo/Redo ialgorithms" iand ifound isomething imarked ias ia iduplicate, ibut
ithe iduplicate iwas ia irequest ifor ia i"Undo iDesign iPattern". iI'd ireally ilike ian ialgorithm ifor ithis.
iI idon't ithink iI inecessarily ineed ia idesign ipattern.

Algorithms:
An ialgorithm iis ilike ia irecipe: ia istep-by-step iprocess ifor iperforming isome iactivity.
An ialgorithm iis ia irecipe ifor iperforming isome itask i- ian iunambiguous ifinite iset iof
iinstructions ithat iachieves isome igoal iby ioperating ion ian iinput iand iproducing ian ioutput.
iTypically, ian ialgorithm iis iexpressed iin ia ilanguage-agnostic ipseudo-code, iwhich ican ithen ibe
iimplemented iin ithe ilanguage iof iyour ichoice.

An ialgorithm ion ithe iother iside ican ibe iexpressed iin icode. iIt iis ia isequence iof ioperations ithat
isolve ia ispecific iproblem ifor iany iinput.

Design iPattern:
A idesign ipattern iis ilike ia iblueprint: ian istructured icollection iof iobjects iand iassociations iand
iactions ito iaccomplish isome igoal.

A idesign ipattern iis ia iway iof istructuring iyour icode iin iorder ito ielegantly iexpress ia
irelationship ibetween ifunctional icomponents. iYou imight iuse idesign ipatterns iwithin ithe
iimplementation iof ian ialgorithm. iFor iexample, iyou imight iuse ian ialgorithm ifor ian iin-order
iwalk iof ia itree ito iensure ithat iyou ivisit iall ithe inodes iof ia itree idata istructure iin ia icertain iorder.
iYou imight ialso iimplement ia ivisitor idesign ipattern ito iexpress ihow iyour iimplementation
ireturns icontrol ito ithe icalling icontext ito iindicate ithat ia inode ihas ibeen ivisited. iThis iis inot ipart
iof ithe ialgorithm, ibut ipart iof ithe isoftware idesign, iand ihow iyou istructure ithe iinterfaces ithat
ieach icomponent iof iyour isoftware ican iuse.
A idesign ipattern iis ia irelatively ivague idescription iof ihow ito isolve ia iproblem iat ian
iarchitectural ilevel, iwith iemphasis ion iflexibility iand imaintainability. iAn ialgorithm iis ia iprecise
idescription iof ihow ito icompute isomething ispecific, iwith ian iemphasis ion icorrectness iand
iefficiency.

Data iStructures
You iprobably iknow ithe ibasics iof ithis. iYou ihave iyour iarrays, iintegers, ibooleans, istrings, ias
iwell ias icombination. iA istudy iof ithis ican ireally ihelp iyou iunderstand ihow idata ioperates iand
iwhat imakes iyour iprogramming imore iefficient, irather iwhat idata itype. iFor iexample, ia istring iis
iactually ian iarray iof icharacters i(basically ispeaking) iso iyou ishould iknow ithat icostly iarray
ifunctions iwill ibe ijust ias icostly ifor iyour istrings.
The igreat ithing iabout idata istructures iis ithat iusing ithe icorrect istructure ican iimprove iwhat
iyou’re idoing.

4
Data iStructures iand ihow ithey iwork ialso ihelp iyou ipick iwhat’s ibest. iYou ilearn iwhat
ioperations iare iexpensive iin iterms iof iprocessing iand imemory. iYou ican ialso ilearn ihow ito
icreate iyour iown idata istructures, isort iof. iIf iyou ithink iabout iit, iall idata istructures i(the
i“collection” itype) iare iclasses ithat icongregate iprimary idata istructures itogether iand ifind
iefficient iways iof iaccessing/storing/using idata ivia, iwait ifor iit, ialgorithms.

Question ino. i2
Q. i2. i Answer ithe ifollowing iQuestion iproperly:
There iare itwo imethods ifor ipropagating idata ito iobservers iwith ithe iobserver idesign
ipattern: ithe ipush imodel iand ithe ipull imodel. iWhy iwould ione imodel ibe ipreferable
iover ithe iother? iWhat iare ithe itrade-offs iof ieach imodel?

Answer:

When iimplementing ithe iObserver ipattern, ithere iare itwo imain iapproaches ito iconsider: ithe
i'push' imodel iand ithe i'pull' imodel.

In ithe i'push' imodel, ithe isubject i(i.e. ithe iObservable) isends ithe iobserver ion inotification iall ithe
idata iit iwill ineed. iThe iobserver idoesn't ineed ito iquery ithe isubject ifor iinformation. iIn ithe i'pull'
imodel, ithe isubject imerely inotifies ithe iobserver ithat isomething ihappened, iand ithe iobserver
iqueries ithe isubject ibased ito iget ithe iinformation iit ineeds.

Let's idiscuss ithe ipros iand icons iof iboth iapproaches:

Push iModel:

The imain iadvantage iof ithe i'push' imodel iis ilower icoupling ibetween ithe iobserver iand ithe
isubject. iThe iobserver idoesn't ineed ito iknow ianything iabout ithe isubject iin iorder ito iquery iit. iIf
iit ineeded ito, iwe'd ineed ito ido ione iof ithe ifollowing: iA- ido idown icasting ion ithe iside iof ithe
iobserver iin iorder ito iinvoke iclass-specific iget imethods ion ithe isubject. iThis iis ibad. iB- imake
ithe iObservable iinterface imore iclass-specific, ioffering ispecific iget imethods, ithus imaking ithe
irelationship ibetween ithe iobserver iand isubject iless igeneral iand imaking ithings imore icoupled.

By iimplementing ithe i'push' imodel, iwe iavoid iall iof ithis.

However, ithe idisadvantage iis iless iflexibility: ithe isubject imay inot ialways iknow iwhat iexact
iinformation ithe iobservers ineed iin iorder ito isend iit ito ithem. iThis iwill ioften imean imore
ispecific iObserver iinterfaces, isuch ias iAgeObserver ithat iare inotified iwhen ithe i'age' iof ithe
isubject iis ichanged, iand iHeight iObserver iwhich iare isent ithe icurrent iheight iof ithe isubject ion
inotification.

5
This iis ione ioption. iThe iother iis ithe isubject isending ia iwhole ilot iof iinformation iencapsulated
iin ian iInfo iobject iof isome isort iand ihave ithe iobservers iquery iit ifrom ithere. iBut iagain, iwe
ican't ibe isure iwe're isending ithe icorrect iinfo. iSo iit's ieither ithis, ior iforcing ithe iobservers ito
iimplement imore ispecific iObserver iinterfaces, iwhich itightens ithe icoupling ion ithe iobserver's
iside.

Pull iModel:

I ialready inoted ithe idisadvantages iof ithe i'pull' imodel. iThe iobservers iwould ihave ito iknow
ithings iabout ithe isubject iin iorder ito iquery ithe iright iinformation, iwhich ileads iA- ito idown
icasting i(ugly), ior iB- ifavorably ito imore ispecific iObservable iinterfaces, ithat ioffer imore
ispecific iaccessor imethods. iFor iexample iAgeObservable ioffers ia igetAge() imethod.
The iadvantage iof ithis iis imore iflexibility. iEach iobserver ican idecide ifor iitself iwhat ito iquery,
iwithout irelying ion ithe isubject ito isend ithe icorrect iinformation.

You ishould ichoose ithe istrategy ithat iis ibetter ifor ithe ispecific iproject iyou're iworking ion.
In ireality, iyou'll ialways ihave ispecific iObserver iand iObservable iinterfaces, iso iyou ihave isome
icoupling ibetween ithe isides ianyway.
So ichoose ieither i'pull' ior i'push' iby iwhat ifits iyou ibest.
Do iall iAgeObservers ineed isimply ithe iage iof ithe isubject? iImplement ithe i'push' imodel. iLess
icoupling iand isimpler.
Do iall iHeightObservers ineed ivarying iinformation iabout ithe isubject i- iaka ione ineeds ito iquery
ithe iage itoo, iand isome iother iobject ineeds ito iquery ithe iweight iin iaddition ito ithe iheight?
iImplement ithe i'pull' imodel. iThis iwould iforce iyou ito iadd iaccessors i(getters) ito ithe
iObservable iinterface i(either ithis ior ipass ithe iactual iobject ias ia iparameter iin iits iexplicit itype,
ibut idoing ithis ithrough ithe iinterface iallows iyou ito ideny ithe iobservers iaccess ito ithings ithat
idon't imatter ito ithem). iThis isolution icreates ihigher icoupling, ibut iit's imore iflexible.
Choose iwhat ifits iyour isituation ibest.

Question ino. i3

Q. i3. Differentiate ithe ifollowing iterms:

 Creational iPattern iand iStructural iPattern

Answer:

6
Design ipatterns iare isolutions ito isoftware idesign iproblems iyou ifind iagain iand iagain iin ireal-
world iapplication idevelopment. iPatterns iare iabout ireusable idesigns iand iinteractions iof
iobjects.

The i23 iGang iof iFour i(GoF) ipatterns iare igenerally iconsidered ithe ifoundation ifor iall iother
ipatterns. iThey iare icategorised iin ithree igroups: iCreational, iStructural, iand iBehavioral ias ilisted
ibelow-

1. Creational ipatterns i
are idesign ipatterns ithat ideal iwith iobject icreation imechanisms iand iare iused iin isituations
iwhen ibasic iform iof iobject icreation icould iresult iin idesign iproblems ior iincrease
icomplexity iof ia icode ibase.

These idesign ipatterns iare iall iabout iclass i instantiation ior iobject icreation. iThese ipatterns ican
ibe ifurther icategorized i into iClass-creational ipatterns iand iobject-creational ipatterns. iWhile
iclass-creation ipatterns iuse i inheritance ieffectively i in ithe i instantiation iprocess, iobject-
creation ipatterns iuse idelegation ieffectively ito iget ithe i job idone. i
Creational idesign ipatterns iare ithe iFactory iMethod, iAbstract iFactory, iBuilder, iSingleton,
iObject iPool, iand iPrototype. i

Use icase iof icreational idesign ipattern- i

Suppose ia ideveloper iwants ito icreate ia isimple i DBConnection iclass ito iconnect ito ia idatabase
iand iwants ito iaccess ithe idatabase iat imultiple i locations ifrom icode, igenerally iwhat ideveloper
iwill ido i is icreate ian iinstance iof iDBConnection iclass iand iuse iit ifor idoing idatabase
ioperations iwherever irequired. iWhich iresults iin icreating i multiple iconnections ifrom ithe
idatabase ias ieach iinstance iof iDBConnection iclass iwill ihave ia iseparate iconnection ito ithe
idatabase. iIn iorder ito ideal iwith i it, iwe icreate iDBConnection iclass ias ia isingleton iclass, iso
ithat ionly ione iinstance iof iDBConnection iis icreated iand ia isingle iconnection i is iestablished.
iBecause iwe ican i manage iDB iConnection ivia ione iinstance, iwe ican icontrol i load ibalance,
iunnecessary iconnections, ietc. i

2.Structural idesign ipatterns i

are idesign ipatterns ithat iease ithe idesign iby iidentifying ia isimple iway ito irealise irelationships
ibetween ientities ior idefines ia imanner ifor icreating irelationships ibetween iobjects.
These idesign ipatterns iare iabout iorganizing idifferent iclasses iand iobjects ito iform i larger
istructures iand iprovide inew ifunctionality. i

Structural idesign ipatterns iare iAdapter, iBridge, iComposite, iDecorator, iFacade, iFlyweight,
iPrivate iClass iData, iand iProxy. i

Use iCase iOf iStructural iDesign iPattern- i

7
iWhen i2 i interfaces iare inot icompatible iwith ieach iother iand iwant ito iestablish ia irelationship
ibetween ithem ithrough ian iadapter i it’s icalled ian iadapter idesign ipattern. iAdapter ipattern
iconverts ithe i interface iof ia iclass i into ianother iinterface ior iclass ithat ithe iclient iexpects, ii.e
iadapter i lets iclasses iworks itogether ithat icould inot iotherwise ibecause iof i incompatibility. iso
iin ithese itype iof iincompatible iscenarios, iwe ican igo ifor ithe iadapter ipattern.

 Composite iand iDecorator

Answer:

They iare icompletely idifferent ipatterns. iComposite iis iintended ito icombine iand irepresent
imultiple iobjects ias ia isingle ione i(of ithe isame ibase itype) i- ii.e. i1 ito iMany, iwhile iDecorator
ienhances i(or iadds ion itop iof) ithe icapability iof ia isingle iobject iof ithe isame itype i- ii.e. i1 ito i1.
Both iComposite iand iDecorator ibreak ilayout ito ismaller icomponents i(or isections), isuch ias
iHeader, iMenu, iContent iand iFooter. iEach iof ithese icomponents iis ibuilt ion iseparate ipage i(.jsp
ifile iin ithe icase iof iJava).

When ithe ipage iis irequested, iit iwill itake iall ineeded icomponents iand iput ithem itogether ias ia
ipage. iThe idifference ibetween iComposite iand iDecorator iis ion ithe iway ithe ipage iis
iconstructed.

Composite iallows ithe ichildren icomponents ito idefine iwhat’s ineeded. iFor iexample, iwhen iyou
iload ia iContact ipage, iyou itell ithe iframework ithat ithe imain icomponent ito iload iis iContact. iThe
iframework iknows iContact icomponent ineeds iHeader, iContent iand iFooter icomponents. iIt iwill
ithen iload iall ithe idependencies icomponents, istick ithem iinto iContact icomponent. iThe ipage iis
icomplete iand ireturned ito iuser.

Decorator, ion ithe iother ihand, irelies ion ithe iparent i(or imaster ipage) ito idefine iwhat’s ineeded
ifor ia ipage. iTaken ifrom iContact ipage iexample iabove, iDecorator iwill ifirst isee iwhich iparent
icomponent ithe iContact iis iusing, ithen icall ithe iparent icomponent. iFrom ithere, iit iknows ithe
iparent’s idependencies, iconstruct ithe iparent icomponent ialong iwith iits idependencies, ithen istick
ithe iContact icomponent iinto iparent icomponent iwhere iit ibelongs. iIn ithis icase, ithe iparent
icomponent ialso idefine iwhere ithe imain icomponent ishould ibe iplaced.

More idifferences ifrom iTiles iproject isite.

8
Aspect Composite iView Decorator

Reusability The idifferent iparts iof ithe ipage Each idecorator ican ibe ireused, ibut
i(template iand ipieces) ican ibe ireused ithe idecoration iitself ican ibe iapplied
iacross ithe iwhole iapplication. ito ione ipage iat ia itime.

Ease iof Each ipage imust ibe idefined iexplicitly. The idecorator ican ibe iapplied ieven
iconfiguration ito ithe ientire iapplication.

Runtime The ipages ican ibe iconfigured iand Since ione ipage iis idecorated iat ia
iconfiguration iorganized iat iruntime itime, ithis ifeature iis inot ipresent.

Performances Low ioverhead ifor icomposition. The ipage ito ibe idecorated ihas ito ibe
iparsed.

Example:

Use iComposite ipattern iif

1. iYou ineed ito ikeep ieither iobject ior igroup iof iobjects iinside ianother iobject.
2. iand iIf ibehaviour iof igroups iand isingle iobject imight ibe icommon.

Use iDecorator iif

1. iYou ihave ivariations iof ian ioperations iat iruntime
like i:
FileWriter ifile i= inew iFileWriter("test.txt");
BufferedWriter iwriter i= inew iBufferedWriter(file); i//we ican icompose ione istream ifrom ianother

Question ino. i4
Q. i4. Explain ithe irelationship ibetween icommonality/variability ianalysis iand ithe ithree
iperspectives iof ilooking iat ia iproblem. iWhy iis iit ibetter ito istart iout ifocusing ion

9
 imotivations irather ithan ion iimplementation? iGive ian iexample iwhere ithis ihas
ihelped iyou.

Answer:

Relationship ibetween iCommonality i& iVariability iAnalysis:

Commonality ivariability ianalysis ihelps ius ito ifocus ion iinterfaces iand istop ius ifrom ilooking iat
iimplementation itoo isoon. iIt ileads ius ito ihide ithe iimplementation iby ifocussing ion ithe
iabstractions ifirst. iIt iencourages ius ito ilook iat ithe ihigh iand ilow ilevel iaspects iof idesign, ibut
iseparately. iIt ihelps ius ito idesign iby icontract, ithus icreating ian iarchitecture ithat iis imore
itestable.

Commonality iAnalysis:

This iis ithe isearch ifor icommon ielements ithat ihelp ius iunderstand ihow imembers iare ithe isame.
iThey iare:

 Recognized ifrom iexperience i- ie.g. ilots iof idifferent ispecies iof itree ihave ithe
icommonality iof ibeing ia itree.

 Deduced ithrough ianalysis i(abstracted) i- ie.g. ipens iare iwriting iinstruments imade ifrom
iplastic, ihave icaps, isame ishape ietc.

10
 The icommonalities idefine ithe ibasic iconcepts iin ia iproblem idomain. iAvoid ithinking ijust iin
iterms iof idata ior ifunction, ifor iexample, ia ipen iand ia ibook imay ibe iclassed ias icommon ibecause
ithey iare iused ifor iteaching/communication, ior iare iboth iportable.

Varibility iAnalysis:

This iis ithe inext istep iafter ideciding ion ia icommonality. iIt ishould ibe idone iwithin ithe icontext iof
ithe icommonality iby iasking, ihow ido ithese ithings ivary. iUsing ian iexample iof idifferent ikinds
iof ipen, iif ithe icommonality iis i“writing iinstrument”, ithen ithe ivariabilities imight ibe iwhat ithey
ican iwrite ion iand iline ithickness ietc. iHowever, iif ithe icommonality iis i“plastic ithings”, ithen ithe
iprevious ivariabilities idon’t iapply iand iinstead iwe ishould ihave ivariabilities ilike itype iof iplastic
iand iamount iof iplastic.

In ithe icase iof ithe i“writing iinstrument” icommonality, ia i(traditional) ipencil iwould iplug iin ito
ithis imodel. iHowever, iit iwould inot iplug iin ito ithe i“plastic ithings” icommonality. iTherefore, iif
iyou iknow ithat iyou iwant ito iextend iyour icommonality ito iinclude ipencils, ithen i“plastic ithings”
iis iprobably inot ithe icorrect icommonality.

Why iis iit ibetter ito istart iout ifocusing ion imotivations irather ithan ion
iimplementation?

Motivation iis ia icondition ithat iactivates iand isustains ibehavior itoward ia igoal. iIt iis icritical ito
ilearning iand iachievement iacross ithe ilife ispan iin iboth iinformal isettings iand iformal ilearning
ienvironments. iFor iexample, ichildren iwho iare imotivated itend ito ibe iengaged, ipersist ilonger,
ihave ibetter ilearning ioutcomes, iand iperform ibetter ithan iother ichildren ion istandardized
iachievement itests i(Pintrich, i2003). iMotivation iis idistinguishable ifrom igeneral icognitive
ifunctioning iand ihelps ito iexplain igains iin iachievement iindependent iof iscores ion iintelligence
itests i(Murayama iet ial., i2013). iIt iis ialso idistinguishable ifrom istates irelated ito iit, isuch ias
iengagement, iinterest, igoal iorientation, igrit, iand itenacity, iall iof iwhich ihave idifferent
iantecedents iand idifferent iimplications ifor ilearning iand iachievement i(Järvelä iand iRenninger,
i2014).

HPL iI1 iemphasized isome ikey ifindings ifrom idecades iof iresearch ion imotivation ito ilearn:

 People iare imotivated ito idevelop icompetence iand isolve iproblems iby irewards iand
ipunishments ibut ioften ihave iintrinsic ireasons ifor ilearning ithat imay ibe imore ipowerful.

 Learners itend ito ipersist iin ilearning iwhen ithey iface ia imanageable ichallenge i(neither
itoo ieasy inor itoo ifrustrating) iand iwhen ithey isee ithe ivalue iand iutility iof iwhat ithey iare
ilearning.

11
 Children iand iadults iwho ifocus imainly ion itheir iown iperformance i(such ias ion igaining
irecognition ior iavoiding inegative ijudgments) iare iless ilikely ito iseek ichallenges iand ipersist
ithan ithose iwho ifocus ion ilearning iitself.

 Learners iwho ifocus ion ilearning irather ithan iperformance ior iwho ihave iintrinsic
imotivation ito ilearn itend ito iset igoals ifor ithemselves iand iregard iincreasing itheir icompetence
ito ibe ia igoal.

 Teachers ican ibe ieffective iin iencouraging istudents ito ifocus ion ilearning iinstead iof
iperformance, ihelping ithem ito idevelop ia ilearning iorientation.

Example:
For iexample, iif ithe igoals iyou ihave icome ifrom iwithin iand ithe ioutcome iis iable ito isatisfy iyour
ipsychological ineeds ifor iautonomy, icompetence, iand irelatedness, ithen ithis iis iintrinsic

imotivation, iand iyou ifound ithe iactivity ito ibe iboth isatisfying iand ienjoyable.

However, iif iyour igoals iare ifixated ion ithe ioutcome iand inone iof iyour ibasic ineeds iare isatisfied,
ithen iyou iare imore ifocused ion iextrinsic imotivation ito igain imoney, ifame, ior ipower iwhile

iavoiding iany iand iall iconsequences.

Question ino. i5
Q.5. i Write ishort inotes ion ithe ifollowing iterms:
 Bridge
 Façade
 Builder
 Prototype

a) Bridge

The iBridge idesign ipattern iallows iyou ito iseparate ithe iabstraction ifrom ithe iimplementation.It iis
ia istructural idesign ipattern.

There iare i2 iparts iin iBridge idesign ipattern i:

1. Abstraction
2. Implementation
12
This iis ia idesign imechanism ithat iencapsulates ian iimplementation iclass iinside iof ian iinterface
iclass.

 The ibridge ipattern iallows ithe iAbstraction iand ithe iImplementation ito ibe ideveloped
iindependently iand ithe iclient icode ican iaccess ionly ithe iAbstraction ipart iwithout ibeing
iconcerned iabout ithe iImplementation ipart.
 The iabstraction iis ian iinterface ior iabstract iclass iand ithe iimplementor iis ialso ian
iinterface ior iabstract iclass.
 The iabstraction icontains ia ireference ito ithe iimplementor. iChildren iof ithe iabstraction
iare ireferred ito ias irefined iabstractions, iand ichildren iof ithe iimplementor iare iconcrete
iimplementors. iSince iwe ican ichange ithe ireference ito ithe iimplementor iin ithe
iabstraction, iwe iare iable ito ichange ithe iabstraction’s iimplementor iat irun-time. iChanges
ito ithe iimplementor ido inot iaffect iclient icode.
 It iincreases ithe iloose icoupling ibetween iclass iabstraction iand iit’s iimplementation.

UML iDiagram iof iBridge iDesign iPattern

13
Elements iof iBridge iDesign iPattern

 Abstraction i– icore iof ithe ibridge idesign ipattern iand idefines ithe icrux. iContains ia
ireference ito ithe iimplementer.
 Refined iAbstraction i– iExtends ithe iabstraction itakes ithe ifiner idetail ione ilevel ibelow.
iHides ithe ifiner ielements ifrom iimplemetors.
 Implementer i– iIt idefines ithe iinterface ifor iimplementation iclasses. iThis iinterface idoes
inot ineed ito icorrespond idirectly ito ithe iabstraction iinterface iand ican ibe ivery idifferent.
iAbstraction iimp iprovides ian iimplementation iin iterms iof ioperations iprovided iby
iImplementer iinterface.
 Concrete iImplementation i– iImplements ithe iabove iimplementer iby iproviding
iconcrete iimplementation.

b) Façade
Facade iis ia ipart iof iGang iof iFour idesign ipattern iand iit iis icategorized iunder iStructural idesign
ipatterns. iBefore iwe idig iinto ithe idetails iof iit, ilet ius idiscuss isome iexamples iwhich iwill ibe
isolved iby ithis iparticular iPattern.

So, iAs ithe iname isuggests, iit imeans ithe iface iof ithe ibuilding. iThe ipeople iwalking ipast ithe
iroad ican ionly isee ithis iglass iface iof ithe ibuilding. iThey ido inot iknow ianything iabout iit, ithe
iwiring, ithe ipipes iand iother icomplexities. iIt ihides iall ithe icomplexities iof ithe ibuilding iand
idisplays ia ifriendly iface.

Examples:
In iJava, ithe iinterface iJDBC ican ibe icalled ia ifacade ibecause, iwe ias iusers ior iclients icreate
iconnection iusing ithe i“java.sql.Connection” iinterface, ithe iimplementation iof iwhich iwe iare inot
iconcerned iabout. iThe iimplementation iis ileft ito ithe ivendor iof idriver.

Another igood iexample ican ibe ithe istartup iof ia icomputer. iWhen ia icomputer istarts iup, iit
iinvolves ithe iwork iof icpu, imemory, ihard idrive, ietc. iTo imake iit ieasy ito iuse ifor iusers, iwe ican
iadd ia ifacade iwhich iwrap ithe icomplexity iof ithe itask, iand iprovide ione isimple iinterface
iinstead.
Same igoes ifor ithe iFacade iDesign iPattern. iIt ihides ithe icomplexities iof ithe isystem iand
iprovides ian iinterface ito ithe iclient ifrom iwhere ithe iclient ican iaccess ithe isystem.

14
 Facade iDesign iPattern iDiagram

c) Builder:
Builder ipattern iaims ito i“Separate ithe iconstruction iof ia icomplex iobject ifrom iits irepresentation
iso ithat ithe isame iconstruction iprocess ican icreate idifferent irepresentations.” iIt iis iused ito
iconstruct ia icomplex iobject istep iby istep iand ithe ifinal istep iwill ireturn ithe iobject. iThe iprocess
iof iconstructing ian iobject ishould ibe igeneric iso ithat iit ican ibe iused ito icreate idifferent
irepresentations iof ithe isame iobject.

UML iDiagram iof iBuilder iDesign iPattern:

15
i
 Product i– iThe iproduct iclass idefines ithe itype iof ithe icomplex iobject ithat iis ito ibe
igenerated iby ithe ibuilder ipattern.
 Builder i– iThis iabstract ibase iclass idefines iall iof ithe isteps ithat imust ibe itaken iin
iorder ito icorrectly icreate ia iproduct. iEach istep iis igenerally iabstract ias ithe iactual
ifunctionality iof ithe ibuilder iis icarried iout iin ithe iconcrete isubclasses. iThe
iGetProduct imethod iis iused ito ireturn ithe ifinal iproduct. iThe ibuilder iclass iis ioften
ireplaced iwith ia isimple iinterface.
 ConcreteBuilder i– iThere imay ibe iany inumber iof iconcrete ibuilder iclasses
iinheriting ifrom iBuilder. iThese iclasses icontain ithe ifunctionality ito icreate ia
iparticular icomplex iproduct.
 Director i– iThe idirector iclass icontrols ithe ialgorithm ithat igenerates ithe ifinal
iproduct iobject. iA idirector iobject iis iinstantiated iand iits iConstruct imethod iis icalled.
iThe imethod iincludes ia iparameter ito icapture ithe ispecific iconcrete ibuilder iobject
ithat iis ito ibe iused ito igenerate ithe iproduct. iThe idirector ithen icalls imethods iof ithe
iconcrete ibuilder iin ithe icorrect iorder ito igenerate ithe iproduct iobject. iOn icompletion
iof ithe iprocess, ithe iGetProduct imethod iof ithe ibuilder iobject ican ibe iused ito ireturn
ithe iproduct.

Example:

Consider ia iconstruction iof ia ihome. iHome iis ithe ifinal iend iproduct i(object) ithat iis ito ibe
ireturned ias ithe ioutput iof ithe iconstruction iprocess. iIt iwill ihave imany isteps ilike ibasement
iconstruction, iwall iconstruction iand iso ion iroof iconstruction. iFinally ithe iwhole ihome iobject iis
ireturned. i

d) Prototype:
16
Prototype iallows ius ito ihide ithe icomplexity iof imaking inew iinstances ifrom ithe iclient. iThe
iconcept i is ito icopy ian iexisting iobject irather ithan icreating ia inew iinstance ifrom iscratch,
isomething ithat i may iinclude icostly ioperations. iThe iexisting iobject iacts ias ia iprototype iand
icontains ithe istate iof ithe iobject. iThe inewly icopied iobject imay ichange isame iproperties ionly
iif irequired. iThis iapproach isaves icostly iresources iand itime, iespecially iwhen ithe iobject
icreation i is ia iheavy iprocess.

The iprototype ipattern i is ia icreational idesign ipattern. iPrototype ipatterns iis irequired, iwhen
iobject icreation iis itime iconsuming, iand icostly ioperation, iso iwe icreate iobject iwith iexisting
iobject iitself. iOne iof ithe ibest iavailable iway ito icreate iobject ifrom iexisting iobjects iare
iclone() imethod. iClone i is ithe isimplest iapproach ito iimplement iprototype ipattern. iHowever,
iit iis i your icall ito idecide ihow ito icopy iexisting iobject ibased ion i your ibusiness imodel.

Prototype iDesign iParticipants:

1) Prototype i: iThis iis ithe iprototype iof iactual iobject.
2) Prototype iregistry i: iThis i is iused ias iregistry iservice ito ihave iall iprototypes
iaccessible iusing isimple istring iparameters.
3) Client i: iClient iwill i be iresponsible ifor iusing iregistry iservice ito iaccess iprototype
iinstances.

When ito iuse ithe iPrototype iDesign iPattern:

1) When ia isystem ishould ibe iindependent iof ihow iits iproducts iare icreated, icomposed,
iand irepresented iand

2) When ithe iclasses ito iinstantiate iare ispecified iat irun-time.

For iexample,

By idynamic iloading ior ito iavoid ibuilding ia iclass ihierarchy iof ifactories ithat iparallels ithe
iclass ihierarchy iof iproducts ior

When i instances iof ia iclass ican ihave ione iof ionly ia ifew idifferent icombinations iof istate. iIt
imay ibe imore iconvenient ito iinstall ia icorresponding inumber iof iprototypes iand iclone ithem
irather ithan i instantiating ithe iclass imanually, ieach itime iwith ithe iappropriate istate.

UML iDiagram iof iPrototype iDesign iPattern:

17
18