An#-Pa'erns SE2811 Jay Urbain, Ph.D. Credits: Gamma, - - PowerPoint PPT Presentation

An#-­‑Pa'erns ¡

SE2811 ¡ Jay ¡Urbain, ¡Ph.D. ¡

Credits: ¡ ¡

• Gamma, ¡Erich; ¡Richard ¡Helm, ¡Ralph ¡Johnson, ¡and ¡John ¡Vlissides ¡(1995). ¡Design ¡

Pa'erns: ¡Elements ¡of ¡Reusable ¡Object-­‑Oriented ¡SoQware. ¡Addison-­‑Wesley. ¡ ¡

• Fowler, ¡Mar#n ¡(2002). ¡Pa'erns ¡of ¡Enterprise ¡Applica#on ¡Architecture. ¡Addison-­‑

Wesley.. ¡

• Head ¡First ¡Design ¡Pa'erns, ¡Freeman ¡& ¡Freeman ¡

2 ¡

What ¡is ¡a ¡Design ¡Pa'ern? ¡

3 ¡

¡A ¡Design ¡Pa'ern ¡is ¡a ¡solu%on ¡to ¡a ¡commonly ¡reoccurring ¡

problem ¡in ¡context, ¡where ¡ – The ¡context ¡is ¡the ¡situa#on ¡in ¡which ¡the ¡pa'ern ¡is ¡applied, ¡ where ¡such ¡situa#ons ¡are ¡encountered ¡repeatedly. ¡ – The ¡solu%on ¡is ¡a ¡general ¡design ¡that ¡can ¡be ¡applied ¡with ¡ small ¡modifica#ons ¡to ¡similar ¡contexts. ¡

Design ¡Pa'erns ¡emerge ¡from ¡the ¡soQware ¡ development ¡community ¡

4 ¡

¡There ¡is ¡no ¡central ¡organiza#on ¡that ¡invents ¡Design ¡Pa'erns ¡

– Pa'erns ¡are ¡“discovered” ¡by ¡soQware ¡developers ¡that ¡ recognize ¡similari#es ¡in ¡solu#ons ¡applied ¡in ¡different ¡

• contexts. ¡

– Pa'erns ¡are ¡“popularized” ¡by ¡soQware ¡developers ¡ cataloging ¡these ¡solu#ons. ¡

Design ¡Pa'erns ¡are ¡categorized ¡by ¡formally ¡ describing ¡their ¡characteris#cs ¡

5 ¡

The ¡“Pa'ern ¡Community” ¡has ¡evolved ¡a ¡de-­‑facto ¡template ¡ ¡outlining ¡a ¡Pa'ern’s ¡ – Name ¡

• A ¡descrip#ve ¡and ¡unique ¡name ¡that ¡helps ¡in ¡iden#fying ¡and ¡referring ¡to ¡the ¡

pa'ern. ¡ – Intent ¡

• Descrip#on ¡of ¡the ¡goal ¡behind ¡the ¡pa'ern ¡and ¡the ¡reason ¡for ¡using ¡it. ¡

– Mo#va#on ¡

• A ¡scenario ¡consis#ng ¡of ¡a ¡problem ¡and ¡a ¡context ¡in ¡which ¡this ¡pa'ern ¡can ¡be ¡
• used. ¡

– Applicability ¡

• Situa#ons ¡in ¡which ¡this ¡pa'ern ¡is ¡usable; ¡the ¡context ¡for ¡the ¡pa'ern. ¡

– Structure ¡

• A ¡graphical ¡representa#on ¡of ¡the ¡pa'ern. ¡

– Consequences ¡

• A ¡descrip#on ¡of ¡the ¡results, ¡side ¡effects, ¡and ¡trade ¡offs ¡caused ¡by ¡using ¡the ¡

pa'ern. ¡ – Sample ¡usage ¡

• An ¡illustra#on ¡of ¡how ¡the ¡pa'ern ¡can ¡be ¡used ¡in ¡a ¡programming ¡language ¡

You ¡can ¡“discover” ¡pa'erns ¡too ¡

6 ¡

Prac#cal ¡experience ¡is ¡vital ¡ – Learn ¡all ¡you ¡can ¡about ¡exis#ng ¡pa'erns ¡ – Write ¡lots ¡of ¡applica#ons ¡ – Reflect ¡on ¡your ¡experiences ¡ – If ¡you ¡have ¡a ¡big ¡idea, ¡contribute ¡it ¡ – See ¡if ¡your ¡idea ¡becomes ¡accepted ¡

All ¡Pa'erns ¡are ¡not ¡beneficial ¡

7 ¡

An#-­‑pa'ern ¡-­‑ ¡ ¡ An ¡an#-­‑pa&ern ¡is ¡a ¡design ¡pa'ern ¡that ¡may ¡be ¡commonly ¡used, ¡ but ¡is ¡ineffec#ve ¡or ¡counterproduc#ve ¡in ¡prac#ce. ¡

• The ¡term ¡was ¡coined ¡in ¡1995 ¡by ¡Andrew ¡Koenig ¡and ¡inspired ¡

by ¡the ¡Gang ¡of ¡Four's ¡book ¡Design ¡Pa&erns, ¡which ¡developed ¡ the ¡concept ¡of ¡design ¡pa'erns ¡in ¡the ¡soQware ¡field. ¡ ¡

• The ¡term ¡was ¡widely ¡popularized ¡three ¡years ¡later ¡by ¡the ¡

book ¡An#Pa&erns ¡by ¡Phillip ¡Laplante ¡and ¡Colin ¡Neill, ¡which ¡ extended ¡the ¡use ¡of ¡the ¡term ¡beyond ¡the ¡field ¡of ¡so7ware ¡ design ¡and ¡into ¡general ¡social ¡interac#on. ¡ ¡

What ¡is ¡an ¡An#-­‑Pa'ern? ¡

8 ¡

Two ¡key ¡elements ¡should ¡be ¡present ¡to ¡formally ¡dis#nguish ¡an ¡ actual ¡an#-­‑pa&ern ¡from ¡a ¡simple ¡bad ¡habit, ¡bad ¡prac#ce, ¡or ¡ bad ¡idea: ¡

• Some ¡repeated ¡pa&ern ¡of ¡ac#on, ¡process, ¡or ¡structure ¡that ¡

ini#ally ¡appears ¡to ¡be ¡beneficial, ¡but ¡ul#mately ¡produces ¡ more ¡bad ¡consequences ¡than ¡beneficial ¡results. ¡

• A ¡refactored ¡solu#on ¡exists ¡that ¡is ¡clearly ¡documented, ¡

proven ¡in ¡actual ¡prac#ce ¡and ¡repeatable. ¡

¡ ¡

What ¡is ¡an ¡An#-­‑Pa'ern? ¡

9 ¡

• Note: ¡

– Many ¡an#-­‑pa'ern ¡ideas ¡amount ¡to ¡li'le ¡more ¡than ¡ mistakes, ¡unsolvable ¡problems, ¡or ¡bad ¡prac#ces ¡to ¡be ¡ avoided ¡if ¡possible. ¡ – Refers ¡to ¡classes ¡of ¡commonly ¡reinvented ¡bad ¡solu#ons ¡to ¡

• problems. ¡ ¡

¡

Objec#ve ¡of ¡An#-­‑Pa'ern? ¡

10 ¡

• By ¡formally ¡describing ¡repeated ¡mistakes, ¡one ¡can ¡recognize ¡

the ¡forces ¡that ¡lead ¡to ¡their ¡repe##on ¡and ¡learn ¡how ¡others ¡ have ¡refactored ¡themselves ¡out ¡of ¡these ¡broken ¡pa'erns. ¡

Object-­‑oriented ¡design ¡an#-­‑pa'erns ¡

11 ¡

• Anemic ¡Domain ¡Model: ¡ ¡

– The ¡use ¡of ¡domain ¡model ¡without ¡any ¡business ¡logic. ¡ ¡

• BaseBean: ¡ ¡

– Inheri#ng ¡func#onality ¡from ¡a ¡u#lity ¡class ¡rather ¡than ¡delega#ng ¡to ¡it. ¡ ¡

• Call ¡super: ¡ ¡

– Requiring ¡subclasses ¡to ¡call ¡a ¡superclass's ¡overridden ¡method. ¡

• Circle-­‑ellipse ¡problem: ¡ ¡

– Subtyping ¡variable-­‑types ¡on ¡the ¡basis ¡of ¡value-­‑subtypes. ¡Subtype ¡polymorphism ¡issues. ¡ – ¡The ¡problem ¡illustrates ¡the ¡difficul#es ¡which ¡can ¡occur ¡when ¡a ¡base ¡class ¡ contains ¡methods ¡which ¡mutate ¡an ¡object ¡in ¡a ¡manner ¡which ¡might ¡invalidate ¡a ¡ (stronger) ¡invariant ¡found ¡in ¡a ¡derived ¡class. ¡

• Circular ¡dependency: ¡ ¡

– Introducing ¡unnecessary ¡direct ¡or ¡indirect ¡mutual ¡dependencies ¡between ¡objects ¡or ¡ soQware ¡modules. ¡

• Constant ¡interface: ¡ ¡

– Using ¡interfaces ¡to ¡define ¡constants. ¡

Object-­‑oriented ¡design ¡an#-­‑pa'erns ¡

12 ¡

• God ¡object: ¡ ¡

– Concentra#ng ¡too ¡many ¡func#ons ¡in ¡a ¡single ¡part ¡of ¡the ¡design ¡(class). ¡

• Object ¡cesspool: ¡ ¡

– Reusing ¡objects ¡whose ¡state ¡does ¡not ¡conform ¡to ¡the ¡(possibly ¡implicit) ¡contract ¡for ¡re-­‑

• use. ¡
• Object ¡orgy: ¡ ¡

– Failing ¡to ¡properly ¡encapsulate ¡objects ¡permiqng ¡unrestricted ¡access ¡to ¡their ¡internals. ¡

• Poltergeists: ¡ ¡

– Objects ¡whose ¡sole ¡purpose ¡is ¡to ¡pass ¡informa#on ¡to ¡another ¡object. ¡

• Sequen#al ¡coupling: ¡ ¡

– A ¡class ¡that ¡requires ¡its ¡methods ¡to ¡be ¡called ¡in ¡a ¡par#cular ¡order. ¡

• Yo-­‑yo ¡problem: ¡ ¡

– A ¡structure ¡(e.g., ¡of ¡inheritance) ¡that ¡is ¡hard ¡to ¡understand ¡due ¡to ¡excessive ¡ fragmenta#on. ¡

SoQware ¡design ¡an#-­‑pa'erns ¡

13 ¡

• Abstrac#on ¡inversion: ¡ ¡

– Not ¡exposing ¡implemented ¡func#onality ¡required ¡by ¡users, ¡so ¡that ¡they ¡re-­‑implement ¡it ¡ using ¡higher ¡level ¡func#ons ¡

• Ambiguous ¡viewpoint: ¡ ¡

– Presen#ng ¡a ¡model ¡(usually ¡Object-­‑oriented ¡analysis ¡and ¡design ¡without ¡specifying ¡its ¡ viewpoint, ¡i.e., ¡intent). ¡

• Big ¡ball ¡of ¡mud: ¡ ¡

– A ¡system ¡with ¡no ¡recognizable ¡structure. ¡

• Database-­‑as-­‑IPC: ¡ ¡

– Using ¡a ¡database ¡as ¡the ¡message ¡queue ¡for ¡rou#ne ¡interprocess ¡communica#on ¡where ¡ a ¡much ¡more ¡lightweight ¡mechanism ¡would ¡be ¡suitable. ¡

• Gas ¡factory: ¡ ¡

– An ¡unnecessarily ¡complex ¡design. ¡

• Gold ¡pla#ng: ¡ ¡

– Con#nuing ¡to ¡work ¡on ¡a ¡task ¡or ¡project ¡well ¡past ¡the ¡point ¡at ¡which ¡extra ¡effort ¡is ¡ adding ¡value. ¡

SoQware ¡design ¡an#-­‑pa'erns ¡

14 ¡

• Inner-­‑plarorm ¡effect: ¡ ¡

– A ¡system ¡so ¡customizable ¡as ¡to ¡become ¡a ¡poor ¡replica ¡of ¡the ¡soQware ¡development ¡

• plarorm. ¡
• Input ¡kludge: ¡ ¡

– Failing ¡to ¡specify ¡and ¡implement ¡the ¡handling ¡of ¡possibly ¡invalid ¡input. ¡

• Interface ¡bloat: ¡ ¡

– Making ¡an ¡interface ¡so ¡powerful ¡that ¡it ¡is ¡extremely ¡difficult ¡to ¡implement. ¡

• Magic ¡pushbu'on: ¡ ¡

– Coding ¡implementa#on ¡logic ¡directly ¡within ¡interface ¡code, ¡without ¡using ¡abstrac#on. ¡

• N-­‑Frame: ¡ ¡

– Sca'ering ¡business ¡logic ¡through ¡mul#ple ¡layers ¡of ¡#ghtly-­‑coupled ¡wrapping ¡ components ¡in ¡order ¡to ¡proclaim ¡abstrac#on ¡and ¡separa#on ¡of ¡concerns. ¡

• Race ¡hazard: ¡ ¡

– Failing ¡to ¡see ¡the ¡consequence ¡of ¡different ¡orders ¡of ¡events. ¡

• Stovepipe ¡system: ¡ ¡

– A ¡barely ¡maintainable ¡assemblage ¡of ¡ill-­‑related ¡components. ¡

Jay’s ¡pa'ern-­‑an#-­‑pa'ern ¡

15 ¡

Key ¡to ¡good ¡OO ¡design: ¡

• Iden#fy ¡what ¡varies ¡in ¡your ¡design ¡and ¡encapsulate ¡it ¡with ¡the ¡appropriate ¡

design ¡pa'ern. ¡

• Do ¡not ¡use ¡complex ¡object ¡structures ¡and ¡interac#ons ¡if ¡your ¡design ¡does ¡

not ¡call ¡for ¡it. ¡

• Less ¡is ¡more, ¡complexity ¡is ¡our ¡enemy. ¡

Code ¡“smell” ¡

16 ¡

• Code ¡smell ¡is ¡any ¡symptom ¡in ¡the ¡source ¡code ¡of ¡a ¡program ¡that ¡possibly ¡

indicates ¡a ¡deeper ¡problem. ¡

• OQen ¡the ¡deeper ¡problem ¡hinted ¡by ¡a ¡code ¡smell ¡can ¡be ¡uncovered ¡when ¡

the ¡code ¡is ¡subjected ¡to ¡a ¡short ¡feedback ¡cycle ¡where ¡it ¡is ¡refactored ¡in ¡ small, ¡controlled ¡steps, ¡and ¡the ¡resul#ng ¡design ¡is ¡examined ¡to ¡see ¡if ¡there ¡ are ¡any ¡further ¡code ¡smells ¡that ¡indicate ¡the ¡need ¡of ¡more ¡refactoring. ¡ ¡

• From ¡the ¡point ¡of ¡view ¡of ¡a ¡programmer ¡charged ¡with ¡performing ¡

refactoring, ¡code ¡smells ¡are ¡heuris%cs ¡to ¡indicate ¡when ¡to ¡refactor, ¡and ¡ what ¡specific ¡refactoring ¡techniques ¡to ¡use. ¡Thus, ¡a ¡code ¡smell ¡is ¡a ¡driver ¡ for ¡refactoring. ¡

• The ¡was ¡coined ¡by ¡Kent ¡Beck ¡in ¡the ¡late ¡1990s. ¡Usage ¡of ¡the ¡term ¡

increased ¡aQer ¡it ¡was ¡featured ¡in ¡Refactoring. ¡Improving ¡the ¡Design ¡of ¡ Exis%ng ¡Code. ¡

Code ¡“smell” ¡

17 ¡

• Determining ¡what ¡is ¡and ¡is ¡not ¡a ¡code ¡smell ¡is ¡oQen ¡a ¡subjec#ve ¡

judgment, ¡and ¡will ¡oQen ¡vary ¡by ¡language, ¡developer ¡and ¡development ¡

• methodology. ¡ ¡
• There ¡are ¡tools, ¡such ¡as ¡Checkstyle, ¡PMD ¡and ¡FindBugs ¡for ¡Java, ¡to ¡

automa#cally ¡check ¡for ¡certain ¡kinds ¡of ¡code ¡smells. ¡

Common ¡code ¡smells ¡

18 ¡

• Duplicate ¡code: ¡ ¡

– Iden#cal ¡or ¡very ¡similar ¡code ¡exists ¡in ¡more ¡than ¡one ¡loca#on. ¡

• Large ¡method: ¡ ¡

– A ¡method, ¡func#on, ¡or ¡procedure ¡that ¡has ¡grown ¡too ¡large. ¡

• Large ¡class: ¡ ¡

– A ¡class ¡that ¡has ¡grown ¡too ¡large. ¡(God ¡object). ¡

• Feature ¡envy: ¡ ¡

– A ¡class ¡that ¡uses ¡methods ¡of ¡another ¡class ¡excessively. ¡

• Inappropriate ¡in%macy: ¡ ¡

– A ¡class ¡that ¡has ¡dependencies ¡on ¡implementa#on ¡details ¡of ¡another ¡

• class. ¡

Common ¡code ¡smells ¡

19 ¡

• Refused ¡bequest: ¡ ¡

– A ¡class ¡that ¡overrides ¡a ¡method ¡of ¡a ¡base ¡class ¡in ¡such ¡a ¡way ¡that ¡the ¡ contract ¡of ¡the ¡base ¡class ¡is ¡not ¡honored ¡by ¡the ¡derived ¡class. ¡(Liskov ¡ subs#tu#on ¡principle). ¡

• Lazy ¡class: ¡ ¡

– A ¡class ¡that ¡does ¡too ¡li'le. ¡

• Contrived ¡complexity: ¡ ¡

– Forced ¡usage ¡of ¡overly ¡complicated ¡design ¡paBerns ¡where ¡simpler ¡ design ¡would ¡suffice. ¡

• Excessively ¡long ¡iden%fiers: ¡ ¡

– In ¡par#cular, ¡the ¡use ¡of ¡naming ¡conven#ons ¡to ¡provide ¡ disambigua#on ¡that ¡should ¡be ¡implicit ¡in ¡the ¡soQware ¡architecture. ¡

Example ¡Scenario ¡

20 ¡

The ¡GoF ¡pa'erns ¡can ¡make ¡life ¡difficult ¡for ¡a ¡maintenance ¡developer ¡or ¡ applica#on ¡framework ¡user ¡who ¡may ¡lack ¡insight ¡into ¡the ¡use ¡and ¡ mo#va#on ¡of ¡a ¡pa'ern. ¡ The ¡overall ¡"Design ¡Pa'erns" ¡philosophy ¡is ¡really ¡"how ¡can ¡I ¡defer ¡as ¡many ¡ decisions ¡as ¡possible ¡from ¡compile ¡#me ¡to ¡run ¡#me?" ¡ ¡ This ¡makes ¡the ¡code ¡very ¡flexible, ¡but ¡the ¡flexibility ¡is ¡wasted ¡when ¡a ¡designer ¡ writes ¡code ¡using ¡lots ¡of ¡pa'erns ¡and ¡leaves ¡without ¡leaving ¡adequate ¡ comments ¡or ¡documenta#on. ¡

Example ¡HelloWorld ¡

21 ¡

public ¡class ¡HelloWorld ¡{ ¡ public ¡sta#c ¡void ¡main(String[] ¡args) ¡{ ¡ System.out.println("Hello, ¡world!"); ¡ } ¡ } ¡ ¡ … ¡but ¡what ¡if ¡you ¡wanted ¡to ¡dynamically ¡print ¡a ¡string ¡to ¡any ¡device? ¡ ¡ Use ¡ ¡

• ­‑

Strategy ¡

• ­‑

AbstractFactory ¡

Example ¡HelloWorld ¡

22 ¡

public ¡interface ¡MessageStrategy ¡{ ¡ public ¡void ¡sendMessage(); ¡ } ¡ ¡ public ¡abstract ¡class ¡AbstractStrategyFactory ¡{ ¡ public ¡abstract ¡MessageStrategy ¡createStrategy(MessageBody ¡mb); ¡ } ¡ ¡ ¡

¡

Example ¡HelloWorld ¡

23 ¡

public ¡class ¡MessageBody ¡{ ¡ Object ¡payload; ¡ public ¡Object ¡getPayload() ¡{ ¡ ¡return ¡payload; ¡ ¡} ¡ public ¡void ¡configure(Object ¡obj) ¡{ ¡ ¡payload ¡= ¡obj; ¡ } ¡ public ¡void ¡send(MessageStrategy ¡ms) ¡{ ¡ ¡ms.sendMessage(); ¡ } ¡ } ¡ ¡ ¡

¡

Example ¡HelloWorld ¡

24 ¡

public ¡class ¡DefaultFactory ¡extends ¡AbstractStrategyFactory ¡{ ¡ private ¡DefaultFactory() ¡{;} ¡ sta#c ¡DefaultFactory ¡instance; ¡ public ¡sta#c ¡AbstractStrategyFactory ¡getInstance() ¡{ ¡ ¡if ¡(instance==null) ¡instance ¡= ¡new ¡DefaultFactory(); ¡ ¡ ¡return ¡instance; ¡ } ¡ ¡ public ¡MessageStrategy ¡createStrategy(final ¡MessageBody ¡mb) ¡{ ¡ ¡return ¡new ¡MessageStrategy() ¡{ ¡ ¡ ¡MessageBody ¡body ¡= ¡mb; ¡ ¡ ¡public ¡void ¡sendMessage() ¡{ ¡ ¡ ¡Object ¡obj ¡= ¡body.getPayload(); ¡ ¡ ¡System.out.println((String)obj); ¡ ¡} ¡ }; ¡ } ¡} ¡ ¡

Example ¡HelloWorld ¡

25 ¡

public ¡class ¡HelloWorld ¡{ ¡ public ¡sta#c ¡void ¡main(String[] ¡args) ¡{ ¡ ¡MessageBody ¡mb ¡= ¡new ¡MessageBody(); ¡ ¡mb.configure("Hello ¡World!"); ¡ ¡AbstractStrategyFactory ¡asf ¡= ¡DefaultFactory.getInstance(); ¡ ¡MessageStrategy ¡strategy ¡= ¡asf.createStrategy(mb); ¡ ¡mb.send(strategy); ¡ } ¡ } ¡ ¡ ¡ ¡

¡

Example ¡HelloWorld ¡

26 ¡

public ¡class ¡HelloWorld ¡{ ¡ public ¡sta#c ¡void ¡main(String[] ¡args) ¡{ ¡ ¡MessageBody ¡mb ¡= ¡new ¡MessageBody(); ¡ ¡mb.configure("Hello ¡World!"); ¡ ¡AbstractStrategyFactory ¡asf ¡= ¡DefaultFactory.getInstance(); ¡ ¡MessageStrategy ¡strategy ¡= ¡asf.createStrategy(mb); ¡ ¡mb.send(strategy); ¡ } ¡ } ¡ ¡ ¡ ¡

¡