Avoiding Overdesign and Underdesign

BT6 Concurrent!Session!11/14/2013!2:15!PM!

"Avoiding Overdesign and

Underdesign" !!!

Presented by:

Ken Pugh

Net Objectives !!!!!!!!!

Brought(to(you(by:(!

340!Corporate!Way,!Suite!300,!Orange!Park,!FL!32073!888C268C8770!E!904C278C0524!E!sqeinfo@sqe.com!E!www.sqe.com

!!!!Ken!Pugh!!!Net!Objectives!!

A fellow consultant with Net Objectives, Ken Pugh helps companies transform into lean-agile organizations through training and coaching. His special interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly. Ken trains, mentors, and testifies on technology topics from object-oriented design to Linux/Unix. He has written several programming books, including the 2006 Jolt Award winner Prefactoring and his latest Lean-Agile Acceptance Test Driven Development: Better Software Through Collaboration. Ken has helped clients from London to Boston to Sydney to Beijing to Hyderabad. He enjoys snowboarding, windsurfing, biking, and hiking the Appalachian Trail. Reach Ken at ken.pugh@netobjectives.com!

info@netobjec+ves.com000www.netobjec+ves.com0

1" "Copyright"©"2008"Net"Objec6ves."All"Rights"Reserved."" "6"November"2013"

Avoiding(Over(and(

Under(Design(In"Agile"Projects"

"Ken"Pugh"

Fellow"Consultant"Net"Objec6ves"

Agenda"

!  Emergent"Design"–  Code"Quali6es"–  Refactoring"

!  Case"Study"!  Advice"from"the"Gang"of"Four"!  Emergent"Design"In"Ac6on""

Ken"Pugh"

ken.pugh"@netobjec6ves.com"

Photo Size: Height: 2.25 Position: from top left corner Horizontal 0.75 Vertical 1. Picture Style: Simple Black Frame

No code goes in till the test goes on. A journey of two thousand miles begins with a single step.

!  Fellow"Consultant"!  OOA&D,"Design"PaSerns,"Lean,"Scrum,"TestVDriven"

Development"

!  Over"2/5"century"of"soYware"development"experience"

!  Author"of"seven"books,"including:"–  0Prefactoring:0Extreme0Abstrac+on,0Extreme0

Separa+on,0Extreme0Readability00(2006"Jolt"Award)"

–  0Interface0Oriented0Design0

–  Lean0Agile0Acceptance0TestFDriven0Development:0BeHer0SoIware0Through0Collabora+on0

Lean"Enterprise"

Business"

Management"Team"

ASSESSMENTS"CONSULTING"TRAINING"COACHING"

Lean Management Project Management

Kanban / Scrum ATDD / TDD / Design Patterns Emergent Design

Lean for Executives Product Portfolio Management Business Product Owner Scaled Agile Framework

technical" process"

5" """ "6"November"2013"

Emergent(Design(

3(Code(Quali8es(

Predictability"

!  Can’t"predict"how"requirements"going"to"change"!  Can"predict"how"code"will"adapt"to"unpredictable"requirements"changes"

!  How"to"increase"predic6on"abili6es"of"code"quality?"

Ques6on"to"Ask"

! When"working"on"a"mature"system"consider"when"adding"a"new"func6on…"""""""which"task"area"takes"more"6me"" " "–"wri6ng"the"new"func6on"or""

" " "–"integra6ng"it"into"the"system?"

Creeping"Changes"

function() { Do_this; Do_that; Do_something_else; }

Creeping"Changes"(2)""

function() { if (a) {

Do_another_thing: //… }

else { Do_this; Do_that; Do_something_else; }

Creeping"Changes"(3)""

function() { if (a) {

if (b) { Do_another_thing:; //… }

else { Do_one_more_thing; //.. }

} else {

Do_this; Do_that; Do_something_else; }

Cohesion"

!  Cohesion""–  How"“closely"the"opera6ons"in"a"rou6ne"[or"class]"are"related.”""–  Cohesion"as"“clarity”""

!  Because"the"more"opera6ons"are"related"in"a"rou6ne"[or"class]"the"easier"it"is"to"understand"the"code"and"what"it's"intended"to"do."*"

!  Strong"cohesion"related"to"clarity"and"understanding."!  “No"schizophrenic"classes”"

*"Steve(McConnell,"Code0Complete,"1993,"p."81."Note:"This"concept"was"first"described"by"Larry"Constan6ne"in"1975,"but"we"like"McConnell’s"defini6on"best."

Coupling"

!  Coupling""–  Strength"of"a"connec6on"between"two"rou6nes"[or"classes].""–  Coupling"is"a"complement"to"cohesion."""

!  Cohesion"describes"how"strongly"the"internal"contents"of"a"rou6ne"[or"class]"are"related"to"each"other.""

!  Coupling"describes"how"strongly"a"rou6ne"is"related"to"other"rou6nes.""

–  Goal"is"to"create"rou6nes"[and"classes]"with"internal"integrity"(strong"cohesion)"and"small,"direct,"visible,"and"flexible"rela6ons"to"other"rou6nes"[and"classes]"(loose"coupling).”*"

!  Tight"coupling"is"related"to"highly"interconnected"code."

*"Steve(McConnell,"Code0Complete,"1993,"p."81."Note:"This"concept"was"first"described"by"Larry"Constan6ne"in"1975,"but"we"like"McConnell’s"defini6on"best."

Coupling"To"Data"

Global Data

Function One

Function Two

Function Three

Attributes

Method One

Method Two

Method Three

No"Redundancy"

!  "One"Rule"in"One"Place""!  Redundancy"is"not"just:"

–  Redundant"state"–  Redundant"func6ons"

!  It"can"also"be"redundant"rela+onships0

Encapsula6on"

Usual"encapsula6on""!  Data"

–  Hide"from"other"en66es."!  Implementa6on"

–  How"par6cular"func6on"is"implemented"or"whether"it"delegates"to"other"objects"

Also:"(

!  Object"Type"–  Abstract"classes"and"interfaces"hide"implemen6ng"classes."

!  Design"–  Assembling"collabora6ng"classes"with"factory"keeps"clients"decoupled"from"design"

!  Construc6on"–  Encapsula6on"of"construc6on""V"wrap""new"""in"getInstance()"method""

Abstrac6on"

!  Abstrac6on"encompasses"encapsula6on"–  Think"about"what"you"want"done,"not"how"you"want"it"done""

!  “When"You’re"Abstract,"Be"Abstract"All"the"Way”"–  Never"use"a"primi6ve"

!  Example:"–  double"GetCost();""–  AddToOrder(double"price);"

!  Versus"–  Dollar"GetCost();"–  AddToOrder(Dollar"price);""

Observa6on"

!  Reversible"changes"are"oYen"not"equal"in"difficulty"!  Usually"easier"to"deobjec6vey"for"performance"than"it"is"to"objec6vey"for"code"quality""

!  Example:"–  double"GetCost()""""Dollar"GetCost()"

–  Dollar"GetCost()"""double"GetCost()""

Testability"and"Design"

!  Crea6ng"tests"first"is"a"kind"of"design"!  Forces"look"at:"

–  Public"method"defini6ons"

– What"responsibili6es"of"object"are"

!  Easy"testability"6ghtly"correlated"to:"–  Loose"coupling""–  Strong"cohesion"

Testability"

!  Difficult"to"unit"test""code"is"oYen:"–  Tightly(Coupled:""

"I"cannot"test"this"without"instan6a6ng"half"the"system“"

–  Weakly(Cohesive:"""This"class"does"so"much,"the"test"will"be"enormous"and"complex!“"

–  Redundant:"""I'll"have"to"test"this"in"mul6ple"places"to"ensure"it"works"everywhere""

Unit"Tes6ng"

!  Tests"at"low"or"granular"level"!  Test"confirms"that"code"reflects"one"inten6on"of"system"!  Good"test"of"our"thought"process:"

–  If"class"does"one"thing"(strong"cohesion)"!  Then"func6onality"is"testable"

–  If"class"does"not"create"side"effects"in"other"classes,"(loose"coupling),""!  Then"testable"individually"

Testability"and"Contracts"

!  Contracts"–  Seman6c"–"desired"behavior""

–  Syntac6c"–"enforced"by"language""!  Seman6c"contract"enforced"by"syntac6c"contract"requires"less"tes6ng"

!  Example:"–  void"setPriority(int"priority);""versus"

–  void"setPriority(Priority"aPriority);"

Quali6es"and"Pathologies"

!  Strong"cohesion"–  Goal:"classes"do"one"thing"–"easier"to"understand"–  Pathology:"the"“God"object”"is"as"bad"as"it"gets"

!  Proper"coupling"–  Goal:"well"defined"rela6onship"between"objects"–  Pathology:"side"affects"when"have"improper"coupling"

!  No"redundancy"–  Goal:"once"and"only"once"–  Pathology:"a"change"in"one"place"must"be"duplicated"in"another"

!  Readability"–  Goal:"coding"standards"–  Pathology:"nonVreadable"code"

!  Encapsula6on"–  Goal:"hide"data,"type,"implementa6on"–  Pathology:"assump6ons"about"how"something"is"implemented"makes"it"

difficult"to"change"

24" """ "6"November"2013"

Emergent(Design(

Refactoring(

Refactoring"

!  Refactoring:""Improving"the"Design"of"Exis6ng"Code"*"!  “Refactoring"is"the"process"of"changing"a"soYware"system"in"such"a"way"that"it"does"not"alter"the"external"behavior"of"the"code"yet"improves"its"internal"structure.”*"

*0Mar8n(Fowler,"Refactoring:0Improving0the0Design0of0Exis+ng0Code."AddisonVWesley."1999."

Types"of"Refactoring"

Refactoring(Bad(Code(

!  Code""smells""!  Improve"code"quality"

!  Clean"up"code"without"breaking"system"

Refactoring(Good(Code(

!  Code"is""6ght""!  New"Requirement"means"change"in"code"/"design"

! Way"to"make"change"without"breaking"system"

27" """ "6"November"2013"

Case(Study(Monitoring"Microwave""

Communica6ons"Hardware""

Complete"Requirements"

!  Need"to"monitor"both"chips"and"cards"–  Program"requests"status"of"either"and"sends"it"""

!  Over"either"a"TCP/IP"connec6on"or"via"eVmail"(SMTP)""

!  Messages"may"be"encrypted""–  PGP64"bit"or"PGP128"bit"

!  Chip"status"queued"for"sending"up"to"10"minutes"unless"an"error"–  Card"status"sent"immediately"

!  Configura6on"file"gives"transmission"method"to"use"

Accommoda6ng"Change"with"Specializa6on"

!  One"way"problem"could"evolve:"–  Start"with"Chip"and"TCP/IP"–  Add"one"func6on"at"a"6me"–  Accommodate"through"specializa6on"

!  Result"not"preSy"(except"as"in"preSy"common)"

Start"with"ChipTCPIP"Requirement"

ChipTCPIP+ getAndSendStatus()# sendWithTCPIP()

Client

Now"Get"Card"with"SMTP"

ChipTCPIP+ getAndSendStatus()# getStatus()# send()

Client

CardSMTP# getStatus()# send()

BeSer"Way"

Client

ChipTCPIP# getStatus()# send()

CardSMTP# getStatus()# send()

Hardware+ getAndSendStatus()

Then"Get"Chip"with"SMTP"Requirement"

Client Hardware + getAndSendStatus()

Chip # getStatus()

ChipTCP # send()

ChipSMTP # send()

CardSMTP # getStatus() # send()

Finally"Get"Card"with"TCPIP"Requirement"

Client Hardware+ getAndSendStatus()

Chip# getStatus()

Card# getStatus()

ChipTCPIP# send()

ChipSMTP# send()

CardTCPIP# send()

CardSMTP# send()

It"Is,"Of"Course,"Worse0

!  Have"not"discussed"varia6ons"of"encryp6on"– Will"make"things"worse"

!  Using"switches"instead"of"inheritance""– Will"have"coupled"switches"instead"of"class"hierarchy"

Problems"with"This"

!  BriSle.""–  Not"easily"allow"for"new"deriva6ons"of"Card"and"Chip"

!  Or"new"transmission"types"

!  Redundant.""–  Changes"in"send()"in"ChipTCPIP"causes"changes"in"CardTCPIP"

!  Weak"cohesion."""–  Concrete"classes"are"about"mul6ple"things."

!  Mul6ple"varia6ons"cause"combinatorial"(class)"explosion"–  Increases"maintenance"problems"

!  In"Short:""–  Using"inheritance"for"specializa6on"does0not0scale0

Combinatorial"Explosion"

Client Hardware+ getAndSendStatus()

Chip# getStatus()

Card# getStatus()

ChipTCPIP# send()

ChipSMTP# send()

CardTCPIP# send()

CardSMTP# send()

ChipFTP# send()

CardFTP# send()

Tes6ng"

!  10"Varia6ons"of"sending""!  10"Varia6ons"of"encryp6ng""!  10"Varia6ons"of"compressing""

!  How"many"classes"if"use"inheritance?""!  How"many"if"use"delega6on?"""

39" """ "6"November"2013"

Advice(from(the(

Gang(of(Four(

Gang"of"Four"Gives"Us"Guidelines*"

!  Design"to"interfaces"!  Favor"object"delega6on"over"class"inheritance."

Gamma,(E.,(Helm,(R.,(Johnson,(R.,(Vlissides,(J."Design0PaHerns:0Elements0of0Reusable0ObjectFOriented0SoIware,"1995,"pp."18,"20,"29."

Design"to"Interfaces"

!  Determine"interface"for"class""–  Design"to"that,"ignoring"implementa6on"details"

!  Therefore"cannot"couple"to"them"

– What"you"hide"you"can"change"

!  Stay"at"conceptual"level,"while"designing"–  Promotes"Cohesion"

Find"What"Varies"and"Encapsulate"It"

!  Iden6fy"varying"behavior"!  Define"interface"for"behavior""

–  Tailor"as"you"go"–  Extract"varia6ons"resul6ng"from"new"requirements"

–  Put"those"into"their"own"interfaces"

Favor"Delega6on"Over"Inheritance"

!  Define"interface"encapsula6ng"varia6on""!  Use"delega6on"to"instance"of"an"implementa6on""

Socket0

1.  Decouples"concepts"2.  Can"defer"decisions"un6l"run6me"3.  Small"performance"hit"

Socket_cmp1" Socket_cmp2"

Compression0

Cmp1" Cmp2"

Socket"

Class0Inheritance0to0Specialize0 Object0delega+on0

Interface"Oriented"Design"

!  To"save"code,"you"can"use""–  Inheritance""–  Delega6on"to"another"class""

!  Cannot"inherit"from"two"classes"(other"than"C++)"

!  Therefore"either""–  Need"to"determine"the"“most"important”"rela6onship""

Interface"Oriented"Design"(2)"

!  Lean"principle""– Make"commitment"at"the"last"possible"moment""

–  (Or"not"at"all"if"possible)""!  Prefactoring"guideline"

–  Avoid"premature"hierarchiliza6on""–  Don’t"make"hierarchy"unless"it"is"necessary"""

Separate"Use"From"Construc6on"

!  An"object"should"construct"another"object"or"use"another"object"–  But"not"both"

!  Implement"construc6on"with"a"factory""

Concept"/"Varia6ons"

Encryption

"Factory"Example""

// Client Selection enum EncryptionType {Strong, Weak, None}; Encrypt getEncryptInstance(EncryptionType et)

{ switch(et) { case Strong: return new E128(); case Weak: return new E64(); case None: return new E0(); default: throw new Exception( “Look at the EncryptionType”); } }

Factory"For"Two"Strategies"

enum ChipType {ForCommercial, ForUS, ForImportantCustomer}; Chip getChip(ChipType ct) {

switch (ct) { case ForCommercial:

return new Chip(GetEncryptInstance(Weak), GetSendInstance(TCP));

case ForUS: return new Chip(GetEncryptInstance(Strong), GetSendInstance(FTP));

case ForImportantCustomer: return new Chip(GetEncryptInstance(Weak), GetSendInstance(FTP); }}

// Or use table

50" """ "6"November"2013"

Emergent(Design(In"Ac6on"

Emergent"Design"

!  TestVDriven"Development,"integrated"with:"–  High"quality"code"–  Knowledge"of"design"paSerns"–  A~tude"of"building"only"what"you"need"(Agile,"YAGNI)"

!  Allows"for"designs"to"emerge"!  Can"take"advantage"of"what"we"know"

– Without"overbuilding"or"overVdesigning."

Requirements"as"“Stories”"

!  Story(1:"Request"the"status"of"a"chip,"encrypt"it"with"PGP64"bit"encryp6on"and"send"that"status"out"via"TCP/IP"

!  Story(2:"Allow"for"not"encryp6ng"the"status"or"using"either"PGP64"bit"or"PGP128"bit"encryp6on.""A"configura6on"file"will"determine"what"(if"any)"encryp6on"is"needed"

!  Story(3:"Support"transmission"via"an"eVmail"connec6on.""A"configura6on"file"will"determine"which"type"of"transmission"to"use"

!  Story(4:"Support"ge~ng"and"sending"the"status"for"a"card"as"well"

Emergent"Design:"Star6ng"with"Story"1"

!  Request"status"of"a"chip,"encrypt"it"with"PGP64"bit"encryp6on"and"send"that"status"out"via"TCP/IP"

!  Implement"simplest"solu6on"possible:"–  No"extra"func6on"–  Design"for"full"system"will"emerge"via"refactoring"

Thinking"from"a"Testability"Perspec6ve"

! What"do"we"need"to"test?"–  Ge~ng"status"

–  Encryp6ng"a"string"–  Sending"an"encrypted"string"

!  Straigh�orward"to"write"tests"for"individual"methods"! Where"should"the"methods"lie?"! What’s"the"easiest"way?"

TestVFirst"Development"Steps"

1.  Write"a"test"that"expresses"an"intent"of"a"class"in"system"

–  Stub"out"class"(enough"to"allow"the"test"to"compile)"2.  Fail"the"test"(don't"skip"this)"

–  Change"class"just"enough"to"pass"test"3.  Pass"the"test"4.  Examine"class"for"coupling,"cohesion,"redundancy,"and"

clarity"problems."""–  Refactor."

5.  Pass"the"test"6.  Return"to"#1"un6l"all"inten6ons"are"expressed"

Solu6on"Diagrammed"

Chip+ getAndSendStatus()# getStatus()# encrypt()# send()

Encrypt+ encrypt()

TCPIP+ transmit()

Client

Why"Is"this"BeSer?"

!  Clear"what"pieces"do"and"how"they"relate"–  Increases"extensibility"–  Eases"maintainability"

!  Some6mes"requirements"misVlead"us"

Transi6on"

!  Remember:"Two"Kinds"of"Refactoring"1.  Refactoring0Bad0Code:""

!  To"improve"code"quality"

2.  Refactoring0Good0Code:"!  To"implement"new/changed"requirement,"

–  Now"going"to"do"the"second"

Story"2:"Mul6ple"Encryp6ons"

!  Allow"for"using"no"encryp6on,"PGP64"bit"encryp6on"or"PGP128"bit"encryp6on"

Refactoring"Says"to"Restructure"Before"Adding"

!  Refactoring:""–  Change"code"before"adding"new"func6on."–  Keep"func6on"same,"but"restructure"code"to"improve"it"

!  Advantages:"–  If"upVfront"tes6ng,"tests"don’t"need"to"change"

! Doing"same"things"

–  Always"have"something"that"works"–  If"one"step"at"a"6me"and"something"breaks"

! More"likely"to"know"what"caused"it""

How"Can"We"Most"Easily"Test"Things?"

!  Need"to"test"every"encryp6on"! Want"to"deal"with"encryp6ons"same"way."!  Easy"if"have"a"common"interface"for"encryp6ons"!  If"interfaces"aren’t"the"same,"then"either:"

–  Chip"has"to"deal"with"differences""–  Use"design"paSerns"to"hide"varia6ons"

!  Requires"wrapping"differences"

OpenVClosed"Principle"

!  Ivar"Jacobson"said:""–  “All"systems"change"during"their"life"cycles.""This"must"be"borne"in"mind"

when"developing"systems"expected"to"last"longer"than"the"first"version”"

!  Bertrand"Meyer"summarized"this"as:""–  SoYware"en66es"(classes,"modules,"func6ons,"etc.)"should"be"open"for"

extension,"but"closed"for"modifica6on"

!  In"short:"–  Design"modules"so"that"they"never"change."""–  When"requirements"change,"add"new"modules"to"handle"things"

For"a"good"ar6cle"on"the"OpenVClosed"Principle,"see"www.objectmentor.com/publica6ons/ocp.pdf""

Refactoring"to"OpenVClosed"

!  First"refactor"code"so"can"add"new"func6on"following"OCP"

!  Then"add"new"code"

First,"Add"Needed"Interface"and"Factory"

Encrypt+ encrypt()

TCPIP+ transmit()

Encrypt64

Client

Config+ getEncrypt()

Used by Client or Chip

Now,"Can"Put"in"the"New"Func6on"

!  Someone"must"determine"which"encryp6on"to"use"!  Maybe"configura6on"object"can"do"that""

!  Client"object"asks"configura6on"object"what"to"use"!  Chip"object"given"needed"behavior""!  Now"add"encrypt128"and"no"encrypt"op6ons"!  Note:""

–  Chip"object"could"talk"to"configura6on"object"–  Then"Client"must"give"Chip"informa6on"configura6on"object"needs"

Then,"Add"New"Implementa6ons"

Encrypt+ encrypt()

TCPIP+ transmit()

Encrypt64

Client

EncryptNull

Encrypt128

Config+ getEncrypt()

makes one of these

Story"3"

!  Support"transmission"via"an"eVmail"connec6on.""A"configura6on"file"will"determine"which"type"of"transmission"to"use"

!  Testability"suggests"concept"of"Transmission"–  Don’t"have"to"test"all"combina6ons"

!  Design"PaSerns"tell"us"same"thing"

Want"to"Follow"Gang"of"Four"Advice"

!  Because"transmission"will"vary,"–  Encapsulate"it"and"delegate"to"it"from"Chip"

!  To"implement"–  First"pull"out"exis6ng"transmission"func6onality"into"own"class"""

!  No"extra"cost"by"doing"this"now"instead"of"when"possibility"first"no6ced"

Refactor"First"

Encrypt+ encrypt()

Encrypt64

Client

EncryptNull

Encrypt128

Config+ getEncrypt()+ getTransmit()

Transmit+ transmit()

makes one of these

makes this

Add"Other"TransmiSers"

Encrypt+ encrypt()

Encrypt64

Client

EncryptNull

Encrypt128

Config+ getEncrypt()+ getTransmit()

Transmit+ transmit()

makes one of these

Story"4:"Support"Cards"

!  For"tes6ng"reasons"–  Don’t"want"to"have"to"handle"different"func6onal"test"cases"when"we"have"Cards"or"Chips"

– Want"to"handle"them"together"

! Want"Cards"and"Chips"to"appear"to"be"the"same"to"the"Client"

!  Implement"with"twoVstep"RefactorVOCP"shuffle"

First,"Refactor"So"OCP"Can"Apply"

TCPIP"

Encrypt"+ encrypt()"

Encrypt64"

Client"

EncryptNull"

Encrypt128"Config"

+ getEncrypt()"+ getTransmit()"

Used by Client "or Hardware"

Transmit"+ transmit()"

Hardware"+ getAndSendStatus()"# getStatus()"# encrypt()"# send()"

makes one of these"

+getHardware()"

Then,"Add"New"Func6on"

TCPIP"

Encrypt"+ encrypt()"

Encrypt64"

Client"

EncryptNull"

Encrypt128"

Transmit"+ transmit()"

Hardware"+ getAndSendStatus()"# getStatus()"# encrypt()"# send()"

makes one of these"makes one of these"

Config"+ getEncrypt()"+ getTransmit()"

Used by Client "or Hardware"

+getHardware()"

This(is(a(brid

ge(paRern!

"A"Few"Comments"

!  Not"coincidence"or"good"luck"change"is"easy"!  Happened"because"

–  No"redundancy""–  Unrelated"things"in"different"classes"

!  Low"level"dis6nc6ons"easy"to"see"–  Even"if"immediate"benefit"is"not"

!  Use"them"because"they"represent"very"low"cost"– Will"result"in"significant"gains"if"things"change"(which"they"almost"certainly"will)"

75" """ "6"November"2013"

Code(Quali8es((

As(A(Guide(

Using"Coding"Quali6es"

!  Could"arrive"by"following"coding"quali6es.""!  TDD,"DPs"and"CVA"(Commonality/Variability"Analysis)"are"related"to"code"quali6es""–  Easy"to"use,"so"use"them""

!  However,"to"illustrate,"say"started"with:"

!  and"then"got"another"transmiSer."

ChipTCPIP+ getAndSendStatus()# sendWithTCPIP()

Client

Handling"This"in"Chip"Weakens"Cohesion"

!  Handle"varia6on"as:"private void sendStatus(String anInfo) { if (transType== TCPIP) sendStatusTCPIP(anInfo); else sendStatusSMTP(anInfo); }

!  Requires"Chip"class"to"remember"more"detail"about"transmission."–  More"than"how"TCP/IP"works"–  Now""SMTP"stuff""–  This"erodes"cohesion""

!  So"split"out"TransmiSer."

Using"Encapsula6on"

!  Consider"how"to"break"up"func6onality"into"classes"– Where"as"much"as"possible"is"encapsulated""

!  Implementa6on"encapsula6on"implies""–  Pull"out"encryp6on"

!  Design"encapsula6on"means""–  Chip"should"not"know"about"mul6ple"encryp6ons"–  Hence"polymorphism"and"factory"

Different"Approaches"for"Different"Situa6ons"

!  Emergent"Design"allows"forward"mo6on:"– When"certainty"

!  PaSern"Oriented"Design"– When"a"lack"of"certainty"

!  TestVDriven"Development,"supported"by"–  Refactoring"

!  PaSerns"help"us"see""leading"edge""of"new"designs""

80" """ "6"November"2013"

Not(An(Ending,(

But(a(Beginning(

Conclusions(1)"

!  Design"emerges"from:"–  Concepts"and"varia6ons"(Commonality/Variability"Analysis)""–  Abstrac6ons"(and"encapsula6on)"–  Refactoring,"with"adherence"to"good"principles"–  Thinking"about"paSerns,"which"reflect"past"adherence"to"good"principles"

Conclusions"(2)"

!  Agility"requires"flexibility"!  Flexibility"comes"from:"

–  Adherence"to"Good"Principles,"– Maintaining"awareness"of"emergent"design,"

–  Understanding"the"forces"of"change"–  Recognizing"applicable"paSerns"in"a"design"

"! We"can"create"maintainable"code!"

!  Thank"you"

!  Please"fill"out"evalua6ons""

Supplemental(

85" """ "6"November"2013"

Designing(with(

PaRerns(

The"Bridge"PaSern"

!  GoF(Intent:"“DeVcouple"an"abstrac6on"from"its"implementa6on"so"that"the"two"can"vary"independently”*"

!  In"example:"–  Abstrac6on"is"Hardware"V"Chips"and"Cards)"–  Implementa6on"is"oneaspect"of"its"responsibility"(TCP/IP"communica6on"

and"eVmail"communica6on)"

!  All"implementa6ons"must"look"same"to"abstrac6on"

Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software, 1995.

An"Abstrac6on"(Hardware)"Tightly"Coupled"to"Its"Implementa6on"(Transmission)"

Chip + getAndSendStatus()

Card + getAndSendStatus()

ChipTCPIP + getAndSendStatus() # sendWithTCPIP()

ChipSMTP + getAndSendStatus() # sendWithSMTP()

CardTCPIP + getAndSendStatus() # sendWithTCPIP()

CardSMTP + getAndSendStatus() # sendWithSMTP()

Bridge"Would"Tell"Us"to"Build"It"This"Way"

Card + getAndSendStatus() TCPIP

+ sendInfo(string) + start() + done()

SMTP + sendInfo(string)

Transmit + sendInfo(string) + start() + done()

89" """ "6"November"2013"

Refactoring(a(

Poor(Design(

Poor"Design"as"a"Result"of"Using"En66es""and"Behaviors"/"Specializa6on"

ChipTCPIP + getAndSendStatus() # sendWithTCPIP()

ChipSMTP + getAndSendStatus() # sendWithSMTP()

CardTCPIP + getAndSendStatus() # sendWithTCPIP()

CardSMTP + getAndSendStatus() # sendWithSMTP()

Pull"Out"Duplica6on"of"Transmission"

ChipTCPIP + getAndSendStatus()

ChipSMTP + getAndSendStatus()

CardTCPIP + getAndSendStatus()

CardSMTP + getAndSendStatus()

TCPIP + sendTCPIP(string) + start() + done()

SMTP + sendSMTP(string)

Create"Trans0Class"to"Simplify"Things"

ChipTCPIP + getAndSendStatus()

ChipSMTP + getAndSendStatus()

CardTCPIP + getAndSendStatus()

CardSMTP + getAndSendStatus()

TCPIP + sendInfo(string) + start() + done()

Derived"Classes"Now"Not"Needed"

TCPIP + sendInfo(string) + start() + done()

Can"Keep"Reference"in"Hardware"

HWComp + getAndSendStatus()

Transmit + sendInfo(string, int) + start() + done()

TCPIP + sendInfo(string, int) + start() + done()

SMTP + sendInfo(string, int)

Client

95" """ "6"November"2013"

Technical(

Solu8ons(to(Aid(

Scaling(

Keep"Technical"Dependencies"Low"

! Ways"minimize"dependencies"of"different"projects"on"each"other"–  Design"PaSerns"–  APIs"to"return"Value"Objects"– Mocks"to"provide"layering""

!  And"to"avoid"scheduling"dependencies"!  Difficul6es"when"one"project"uses"another"

–  Use"component"tes6ng"as"a"method"of"decoupling"components"–  Implement"with"up"front"testVspecifica6on"and"mocks"

! Minimize"impacts"that"do"occur"with"Test"Driven"Development"

Using"Design"PaSerns"

!  Design"paSerns"–  How"to"deal"with"implementa6ons"at"the"conceptual"level,"i.e.,"through"an"API"

–  If"added"or"changed"implementa6on""! Using"code"does"not"change"

–  Handles"varia6on"!  DP"can"be"used"in"agile"projects"effec6vely.""

Decoupling"Projects"

!  4"Groups"(A,"B,"C,"D)"–  All"use"a"network"maintained"by"E"–  These"groups"all"need"informa6on"from"each"other"–  They"stated"what"info"was"needed"at"start"of"project"

Group"A"

Group"E"

Group"C" Group"D"

Group"B"

Good"Start,"Bad"Finish"

!  New"informa6on"becomes"needed."–  Group"A"needs"something"from"Group"B"

–  Group"B"is"busy"and"not"par6cularly"helpful"–  Group"B"will"not"allow"group"A"to"touch"their"code"

!  How"could"we"have"set"it"up"to"resolve"these"issues?"– While"not"requiring"us"to"be"preVcogni6ve?"

!  Use"the"ValueVObject"PaSern"

Value"Object"PaSern"

!  Have"each"group"have"an"API"that"has:"–  setUp("flag,"GetInfo"useThis)"–"used"to"say"which"value"object"to"use."–  ValueObject"getInfo(flag)"

!  Calling"program"knows"–  Type"of"value"object"to"use""

!  and"the"rou6ne"to"fill"it"out"–  Knows"what"it"gets"back"

!  Can"use"that"par6cular"informa6on"

Shown"in"the"UML"

Group"A"Group"B"

"""+getInfo(flag)"

Group"C"

Group"D"

GetInfo"+ValueObject"getInfo()"

GetInfoForC"+ValueObject"getInfo()"

GetInfoForA"+ValueObject"getInfo()"

GetInfoForD"+ValueObject"getInfo()"

ValueObject"

ValueObjectC"ValueObjectA"

ValueObjectD"

+setUp(flag,"GetInfo"useThis)"""""

How"This"Works"

Group"A"Group"B"

"""+getInfo(flag)"

Group"C"

Group"D"

GetInfo"+ValueObject"getInfo()"

GetInfoForC"+ValueObject"getInfo()"

GetInfoForA"+ValueObject"getInfo()"

GetInfoForD"+ValueObject"getInfo()"

ValueObject"

ValueObjectC"ValueObjectA"

ValueObjectD"

+setUp(flag,"useThis)"""""

Mocks(on(a(Large(

Scale(

Managing"Dependencies"

!  Let’s"say"group"A"needs"to"use"the"system"built"by"group"B""

!  Group"A"specifies"to"Group"B"what"group"B"needs"to"provide"

!  Group"A’s"and"Group"B’s"understanding"is"changing"as"6me"goes"by"

!  How"can"we"manage"this?"

Team"A:"“We"need"this”"

Team"B:"“How"will"we"know"we’ve"done"

that?”"

“When"your"system"does"this”"

How"should"team"B"respond?"

Team"B"should"build"a"mock"of"their"system"

The"mock"sa6sfies"the"tests"that"team"A"specifies"

A’s""System" Uses"

A"Mock"as"Requirements/Test"

!  Note"mock"fulfills"the"following"uses:"–  Defines"the"requirements"for"A"

–  Can"be"used"by"A"to"run"while"team"B"builds"it"–  Is"an"executable"specifica6on"for"team"B"

!  So"they"can"see"if"they"are"building"the"right"thing"!  Tests"that"define"the"mock"can"be"used"as"tests"for"team"B’s"system"

! What"happens"if"team"A’s"or"team"B’s"understanding"changes?"–  The"mock"must"be"updated"

Resources"

!  Resources:"www.netobjec6ves.com/resources""–  Webinars/Training"Videos"(PowerPoint"with"audio)"–  Ar6cles"and"whitepapers"–  Pre/post"course"support"Suppor6ng"materials"–  Quizzes"–  Recommended"reading"paths"

!  Blogs"and"podcasts:"blogs.netobjec6ves.com"!  Annotated"Bibliography"!  AYerVCourse"Support"(students"only)"!  Addi6onal"Training"!  Two"User"Groups"

–  hSp://tech.groups.yahoo.com/group/leanagile""–  hSp://tech.groups.yahoo.com/group/leanprogramming""

Join"our"eVmail"list"to"receive"regular"updates"and"informa6on"about"our"resources"and"training"of"interest"to"you"

Context"

!  How"do"you"avoid"over"and"under"design"in"agile"projects?"

Exercise"

1.  Imagine"a"6me"you"built"something"in"2"steps"(or"more)"and"had"significant"rework"in"later"steps"because"of"not"looking"ahead."That"is,"this"is"the"situa6on"you"are"concerned"about."

2.  Now,"imagine"you"can"go"back"and"do"the"first"step"again"with"the"following"condi6ons:"1.  You"know"everything"you"know"now"2.  You"can"design"it"differently,"but"you"can’t"add"anything"that"

isn’t"needed"for"the"first"step"

3.  How"would"you"design"it?"

Good"Ques6ons"to"Ask"

!  How"would"you"do"your"design"if"you"knew"later"that"whatever"you"did"now"was"wrong?""

112" """ "6"November"2013"

Emergent(Design(Design"PaSerns"and"Refactoring"for"Agile"

Development"

Test:"What"Does"It"Mean?"

!  1(a"chiefly0Bri+sh":(CUPEL"b((1)":"a"cri6cal"examina6on,"observa6on,"or"evalua6on":(TRIAL;"specifically":"the'procedure'of'submi1ng'a'statement'to'such'condi4ons'or'opera4ons'as'will'lead'to'its'proof'or'disproof'or'to'its'acceptance'or'rejec4on(<a"test"of"a"sta6s6cal"hypothesis>"(2)":"a"basis"for"evalua6on":(CRITERION"c":"an"ordeal"or"oath"required"as"proof"of"conformity"with"a"set"of"beliefs""

!  Test"can"be"thought"of:"–  Specifica6on"that"says"you"are"doing"what"you"should"be"doing"

114" """ "6"November"2013"

Inheritance(

Versus(Interface(

Inheritance"Issues""

!  Combines"two"perspec6ves"–  Common"interface"(specifica6on)"

! Derived"classes"play"the"same"role"as"base"class""

–  Common"implementa6on""!  inherited"methods,"aSributes"

!  OYen"mix"up"these"perspec6ves"""

Changing"Base"vs"Interface"

Base Class

Methodone()

Addedmethod() //New

Interface

Methodone()

Addedmethod() // New

Derived Class

Does Addedmethod() need overriding ?

Implementing Class

Addedmethod() needs implementation

Inheritance"Versus"Interface"

BaseClass Method(); NewMethod():

DerivedClass AnotherDerivedClass Method() { anotherway;}

Interface Method(); NewMethod():

ImplementingClass AnotherImplementingClass

What happens if new method added to base class? Is it applicable to all derived classes? Do you know everything that is derived? What if four derived classes and two use same override? Need a helper class

InterfaceHelper Method(); NewMethod(): AnotherWay();

OneMore DerivedClass

Fourth DerivedClass Method() { anotherway;}

OneMoreImplementingClass FourthImplementingClass

Prefactoring"Guideline"

!  Avoid"premature"hierarchiliza6on""–  Don’t"create"hierarchies"un6l"you"really"need"them""

!  It"is"easier"to"create"the"right"hierarchy"than"to"dehierarchalize"the"wrong"one"

Avoiding Overdesign and Underdesign

Technology

Transcript of Avoiding Overdesign and Underdesign

Avoiding Pitfalls and Managing Performance

Open Research Onlineoro.open.ac.uk/71265/3/managing_margins_overdesign_in...clearly identified and a justification given for their use” (BSRIA, 2007). Other factors leading to overdesign

Avoiding catastrophe | Carbon Equity Projectarchive.foe.org.au/sites/default/files/(2007) Avoiding... · 2017-03-07 · Avoiding catastrophe Recent science and new data on global

Avoiding Capsizing and Swamping

VMware vSphere – avoiding an Internal Storm - Metron · VMware vSphere - avoiding an internal storm. 2 ... Using vMotion and DRS, ... VMware vSphere – avoiding an Internal Storm

Detecting and Avoiding Concurrency Bugs

Avoiding The Quick Fix . Avoiding The Quick Fix .

Newsletter of the Musical Engineering Groupelectronotes.netfirms.com/EN215.pdf · “tweaking” or “fine tuning”, or it can be intentional “overdesign” knowing that actual

Best Practices in Avoiding Pad Cratering and Capacitor ... Slides for YouTube/Avoiding-Pad... · Best Practices in Avoiding Pad Cratering and Capacitor Cracking ... o BGAs don’t

Stepping Carefully: Avoiding Legal Traps and …1 Stepping Carefully: Avoiding Legal Traps and Pitfalls in HSA Implementation and Administration Stepping Carefully: Avoiding Legal

Avoiding ITstrategies and investment disasters

AVOIDING THE PITFALLS - Alvarez and Marsal...ALVAREZ & MARSAL AVOIDING THE PITFALLS ALVAREZ & MARSAL AVOIDING THE PITFALLS Implementing a great Integrated Performance Management solution,

Avoiding Greenhouse Gas Emissions The Essential Role … · and not always straightforward. ... • Avoiding Greenhouse Gas Emissions ... Avoiding Greenhouse Gas Emissions The Essential

ROCKFALL PROTECTION & SNOW BARRIERS · Maccaferri’s philosophy is to offer a logical graded range of engineered systems working together with each other, to reduce overdesign and

Avoiding Shock and Awe

AVOIDING UNPLANNED ADMISSIONS ENHANCED SERVICE: PROACTIVE .../media/Employers/Publications/Avoiding... · 1 Avoiding unplanned admissions enhanced service Guidance and audit requirements

DE Recovering and Avoiding Consequential Damages …shutts.com/.../Recovering-and-Avoiding-Consequential-Damages-in-the... · Recovering and Avoiding Consequential Damages in ...

Referencing and avoiding plagiarism

Proving and Avoiding Inequitable Conduct in Patent ...media.straffordpub.com/products/proving-and-avoiding...Proving and Avoiding Inequitable Conduct in Patent Prosecution and Litigation

Effective Writing and Avoiding Plagiarism