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? ¡ ¡ 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 . ¡ 3 ¡
Design ¡Pa'erns ¡emerge ¡from ¡the ¡soQware ¡ development ¡community ¡ ¡ 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. ¡ 4 ¡
Design ¡Pa'erns ¡are ¡categorized ¡by ¡formally ¡ describing ¡their ¡characteris#cs ¡ 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 ¡ 5 ¡
You ¡can ¡“discover” ¡pa'erns ¡too ¡ 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 ¡ 6 ¡
All ¡Pa'erns ¡are ¡not ¡beneficial ¡ 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 . ¡ ¡ 7 ¡
What ¡is ¡an ¡An#-‑Pa'ern? ¡ 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. ¡ ¡ ¡ 8 ¡
What ¡is ¡an ¡An#-‑Pa'ern? ¡ • 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. ¡ ¡ ¡ 9 ¡
Objec#ve ¡of ¡An#-‑Pa'ern? ¡ • 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. ¡ 10 ¡
Object-‑oriented ¡design ¡an#-‑pa'erns ¡ 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. ¡ 11 ¡
Object-‑oriented ¡design ¡an#-‑pa'erns ¡ 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. ¡ 12 ¡
SoQware ¡design ¡an#-‑pa'erns ¡ 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. ¡ 13 ¡
Recommend
More recommend
