Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Four Patterns at the Heart of Good Programming Style

1,969 views

Published on

Four Patterns at the Heart of Good Programming Style

Published in: Software
  • Login to see the comments

Four Patterns at the Heart of Good Programming Style

  1. 1. 1  
  2. 2. 2  
  3. 3. Have  you  read  ‘Code  Complete’  by  Steve  McConnell?     When  I  started  using  Java  in  1997/1998  there  was  quite  a  bit  of  talk  about  it.   3  
  4. 4. As  you  can  see  from  above,  opinion  is  divided  over  its  merits.     I  think  it  is  safe  to  say  that  a  lot  of  people  have  skimmed/read  it  and  may  have  been   influenced  by  it.     We  don’t  have  Nme  to  look  at  the  detail  of  this  but  in  his  book  (both  ediNons)   McConnell  asks  himself  ‘How  long  can  a  method  be?’,  and  to  answer  this  he  looks  at   the  results  of  various  studies.  We  are  going  to  go  straight  to  his  conclusion/answer     4  
  5. 5. 5  
  6. 6. He  acknowledges  that  method  length  can  affect  readability,  but  only  as  it  surpasses   200  lines!     This  presentaNon  is  about  a  different  point  of  view.   6  
  7. 7. This  presentaNon  is  about  ideas  published  by  Kent  Beck   7  
  8. 8. •  Creator  of  Extreme  Programming     •  Credited  with  having  developed  or  'rediscovered'  TDD   •  One  of  the  signatories  of  the  Agile  Manifesto     •  Pioneered  Design  Pa`erns   •  Popularised  Class  Responsibility  CollaboraNon  Cards     •  Created  the  JUnit  framework  with  Erich  Gamma   •  Pioneered  the  commercial  applicaNon  of  Smalltalk       8  
  9. 9. This  presentaNon  is  about  a  specific  point  of  view  on  how  to  organise  program  logic   using  methods     9  
  10. 10. At  the  heart  of  this  viewpoint  are  a  handful  of  simple  pa`erns     10  
  11. 11. Kent  Beck  once  said  that  some  of  his  best  pa`erns  are  those  that  he  thought   someone  would  laugh  at  him  for  wriNng.       11  
  12. 12. This  is  the  kind  of  pa`ern  we  are  going  to  look  at       So  although  at  Nmes  you  may  find  it  hard  not  to  laugh  at  the  simplicity  of  the   pa`erns     SIMPLE  <>  EASY   It  is  not  necessarily  easy/trivial  to  apply  them     I  think  there  is  value  in  being  aware  of  the  pa`erns  when  programming     Also,  the  message  of  this  presentaNon  is  not  just  the  pa`erns  per  se  but  also  the   wider  narraNve  around  them     12  
  13. 13. Kent  Beck’s  books  in  which  he  describes  the  pa`erns   13  
  14. 14. The  two  books  cover  similar  ground     But  they  are  quite  different,  and  in  some  ways  they  complement  each  other   IP  is     higher  level  than  SBPP   more  philosophical   not  so  pracNcal  –  very  li`le  code  in  it     Although  I’ll  be  concentraNng  on  SBPP,  there  will  be  a  couple  of  excepNons,  e.g.  right   now:  I  want  to  tell  you  about  Kent  Beck’s  mo#va#on  for  the  pa`erns  (chapter  4  of   ImplementaNon  Pa`erns)     14  
  15. 15. In  the  bibliography  of  ImplementaNon  Pa`erns,  we  find:     Edward  Yourdon  and  Larry  ConstanNne,  Structured  Design:  Fundamentals  of  a   Discipline  of  Computer  Program  and  Systems  Design,  PrenNce  Hall,  1979.  ISBN   0138544719.   This  book  presents  the  equivalent  of  the  laws  of  physics  for  so4ware   design     15  
  16. 16. Beck  says  that  30  years  ago  Yourdon  and  ConstanNne  idenNfied  Economics  as  the   underlying  driver  of  so4ware  design     16  
  17. 17. Sonware  should  be  designed  to  reduce  its  overall  cost       17  
  18. 18. COSTtotal  =  COSTdevelop  +  COSTmaintain     The  cost  of  maintenance  is  much  higher  than  the  iniNal  cost  of  development     18  
  19. 19. Maintenance  is  expensive  because  understanding  exisNng  code  is  Nme-­‐consuming   and  error-­‐prone     19  
  20. 20. Making  changes  is  generally  easy  once  you  know  what  needs  changing     20  
  21. 21. COSTmaintain  =    COSTunderstand  +  COSTchange+  COSTtest+  COSTdeploy       Learning  what  the  code  does  is  the  expensive  part       21  
  22. 22. One  strategy  for  reducing  overall  cost  is  to  invest  more  in  iniNal  development  in  hope   of  reducing  or  eliminaNng  the  need  for  change     22  
  23. 23. Such  efforts  have  generally  failed     23  
  24. 24. Beck’s  strategy  for  reducing  overall  costs  is  to  ask  all  programmers  to  address  the   cost  of  understanding  code  during  the  maintenance  phase,  by  communicaNng   programmer  to  programmer     24  
  25. 25. The  immediate  benefits  of  clear  code  are  fewer  defect,  easier  sharing  of  code,  and   smoother  development     25  
  26. 26. 1997  –  Smalltalk  Best  PracNce  Pa`erns     This  book  is  about  the  simple  things  experienced,  successful  Smalltalkers  do  that   beginners  don’t     In  a  sense,  it’s  a  style  guide     It  covers  the  daily  tac#cs  of  programming:   How  do  you  choose  names  for  objects,  variables  and  methods?   How  do  you  break  logic  into  methods?   How  do  you  communicate  most  clearly  through  your  code?     26  
  27. 27. The  advice  is  broken  into  92  pa`erns   Each  pa`ern  presents:   A  recurring  daily  programming  problem   The  tradeoffs  that  affect  the  soluNon  to  the  problem;  and   A  concrete  recipe  to  crate  a  soluNon  for  the  problem   The  pa`erns  don’t  stand  in  isolaNon   They  form  a  system  or  language     27  
  28. 28. That’s  a  lot  of  pa`erns       28  
  29. 29. But  Don’t  worry:  we  are  only  going  to  look  at  4   These  are     Fundamental  –  key  to  achieving  good  style   Interrelated  –  they  form  their  own  subsystem   Very  simply  stated  –  but  have  far  reaching  effects     29  
  30. 30. 30  
  31. 31. Some  things  are  hard  to  define     Faced  with  the  prospect  of  defining  the  term  ‘obscenity’,  a  US  Supreme  Court  JusNce   once  said:  “I  know  it  when  I  see  it,  and  the  moNon  picture  involved  in  this  case  is  not   that”.     Wikipedia  says:  The  phrase  "I  know  it  when  I  see  it"  is  a  colloquial  expression  by   which  a  speaker  a`empts  to  categorize  an  observable  fact  or  event,  although  the   category  is  subjecNve  or  lacks  clearly  defined  parameters.     Here  is  a  book  on  Quality  whose  Ntle  uses  the  expression  in  its  Ntle.     31  
  32. 32. Beck  says  Good  Programming  Style  is  one  of  those  things  that  everyone  knows  when   they  see  it,  but  is  very  hard  to  ar#culate  precisely.       32  
  33. 33. He  says  “There  are  a  few  things  I  look  for  that  are  good  predictors  of  whether  a   project  is  in  good  shape.  These  are  also  proper#es  I  strive  for  in  my  code.”     33  
  34. 34. Once  and  only  once  (OAOO)       If  I  only  have  one  minute  to  describe  good  style,  I  reduce  it  to  a  simple  rule:  In  a   program  wri`en  with  good  style,  everything  is  said  once  and  only  once.       This  isn't  much  help  in  creaNng  good  code,  but  it's  a  darned  good  analyNc  tool.       34  
  35. 35. If  I  see  several  methods  with  the  same  logic,  several  objects  with  the  same  methods,   or  several  systems  with  similar  objects,  I  know  this  rule  isn't  saNsfied.       This  leads  us  to  the  second  property…     35  
  36. 36. Lots  of  li`le  pieces       Good  code  invariably  has  small  methods  and  small  objects.         36  
  37. 37. Only  by  factoring  the  system  into  many  small  pieces  of  state  and  funcNon  can  you   hope  to  saNsfy  the  "once  and  only  once"  rule.       37  
  38. 38. I  get  lots  of  resistance  to  this  idea,  especially  from  experienced  developers,  but  no   one  thing  I  do  to  systems  provides  as  much  help  as  breaking  it  into  more  pieces.       When  you  are  doing  this,  however,  you  must  always  be  certain  that  you   communicate  the  big  picture  effecNvely.       38  
  39. 39. OAOO  depends  on  Lots  of  Li`le  Pieces   39  
  40. 40. Good  style  leads  to  easily  replaceable  objects.     40  
  41. 41. In  a  really  good  system,  every  Nme  the  user  says  "I  want  to  do  this  radically  different   thing,"  the  developer  says,  "Oh,  I'll  have  to  make  a  new  kind  of  X  and  plug  it  in."       When  you  can  extend  a  system  solely  by  adding  new  objects  without  modifying  any   exisNng  objects,  then  you  have  a  system  that  is  flexible  and  cheap  to  maintain.         41  
  42. 42. It  seems  to  me  Beck  here  is  referring  to  Bertrand  Meyer’s  “Open  Closed  Principle”     42  
  43. 43. You  can't  do  this  if  you  don't  have  lots  of  liDle  pieces.     43  
  44. 44. One  more  indicator/predictor  depending  on  Lots  of  Li`le  Pieces   44  
  45. 45. Moving  Objects     Another  property  of  systems  with  good  style  is  that  their  objects  can  be  easily  moved   to  new  contexts.         45  
  46. 46. You  should  be  able  to  say.  "This  object  in  this  system  does  the  same  job  in  that   system.  ...       Then,  if  you  have  a  system  built  with  lots  of  liDle  pieces,  you  will  be  able  to  make   the  necessary  modificaNons  and  generalizaNons  fairly  easily.     46  
  47. 47. One  more  indicator/predictor  depending  on  Lots  of  Li`le  Pieces     47  
  48. 48. Don't  put  two  rates  of  change  together.       •  Don't  have  part  of  a  method  that  changes  in  every  subclass  with  parts  that  don't   change.     •  Don't  have  some  instance  variables  whose  value  changes  every  second  in  the   same  object  with  instance  variables  whose  values  change  once  a  month.     •  Don't  have  a  collecNon  where  some  elements  are  added  and  removed  every   second  and  some  elements  are  added  and  removed  once  a  month.     •  Don't  have  code  in  an  object  that  has  to  change  for  every  piece  of  hardware,  and   code  that  has  to  change  for  every  operaNng  system.     •  How  do  you  avoid  this  problem?  You  got  it,  lots  of  li`le  pieces.       48  
  49. 49. The  5  (1  +  4)  properNes  (predictors  )  of  systems  wri`en  in  good  style  (of  projects  in   good  shape)     49  
  50. 50. For  those  familiar  with  Fowler’s  ‘Refactoring’,  it  is  not  IMHO  a  coincidence  what  the   first  three  smells  are  in  the  book’s  sNnk  parade  (see  next  slide).       50  
  51. 51. The  book  was  published  two  years  aner  SBPP  and  Kent  Beck  was  one  of  the   collaborators  on  the  ‘smells’  topic.     51  
  52. 52. Methods  are  important  to  the  system  because  they  are  how  work  gets  done  in   Smalltalk.       52  
  53. 53. Just  as  important,  methods  are  the  way  you  communicate  to  readers  how  you   intended  for  work  to  get  done.       53  
  54. 54. You  must  write  your  methods  with  both  of  these  audiences  in  mind.       Readers  of  the  code,  who  are  more  interested  in  the  ‘what’,  and  the  computer,  which   is  interested  in  the  ‘how’.     54  
  55. 55. Methods  must  do  the  work  they  are  supposed  to  do  but  they  must  also   communicate  the  intent  of  the  work  to  be  done.     55  
  56. 56. It  is  important  to  disNnguish  between  INTENTION  (WHAT)    and  HOW   (IMPLEMENTATION)     That  is  the  Chinese  ideogram  for  Intent/IntenNon   56  
  57. 57. Methods  decompose  the  funcNon  of  your  program  into  easily  diges#ble  chunks.       57  
  58. 58. Carefully  breaking  a  computa#on  into  methods  and  carefully  choosing  their  names   58  
  59. 59. communicates  more  about  your  inten#ons  to  a  reader  than  any  other  programming   decision,  besides  class  naming.     59  
  60. 60. So  one  of  the  Benefits  of  Methods    is  CommunicaNon   60  
  61. 61. Another  benefit  of  methods  is  flexibility     Methods  are  the  granularity  of  overriding.  A  well  factored  superclass  can  always  be   specialized  by  overriding  a  single  method,  without  having  to  copy  part  of  the   superclass  code  into  the  subclass.     61  
  62. 62. Recap:  two  benefits  of  methods  are  communicaNon  and  flexibility   62  
  63. 63. But  Methods  don't  come  for  free.       Their  cost  is  management  overhead.     63  
  64. 64. Managing  all  those  bits  and  pieces  of  code  -­‐  wriNng  them  in  the  first  place,  naming   them,  remembering,  rediscovering,  and  communicaNng  how  they  all  fit  together   64  
  65. 65. This  mgmt  overhead  takes  Nme.     If  there  is  no  benefit  to  be  gained,  bigger  methods  would  be  beDer  than  small   because  of  the  reduced  management  overhead.     65  
  66. 66. Methods  cost  in  performance  as  well.     66  
  67. 67. Each  method  invocaNon  takes  precious  computer  cycles.     67  
  68. 68. The  trick  to  geIng  good  performance  is  using  methods  as  a  lever  to  make  your   performance  measurement  and  tuning  more  effecNve.       68  
  69. 69. In  my  experience,  beDer  factored  code,  with  lots  of  small  methods,  both  allows   more  accurate  and  concise  performance  measurement  (because  there  aren't  li`le   snippets  of  code  duplicated  all  over)  and  provides  leverage  for  tuning  (through   techniques  like  Caching  Instance  Variable).     69  
  70. 70. From  ImplementaNon  Pa`erns:     •  As  I  was  wriNng  this  I  wrote  a  li`le  benchmark  program  that  compared  a  million   loop  itera#ons  with  a  million  messages   70  
  71. 71. •  The  overhead  was  20-­‐30%  on  average,  not  enough  to  affect  the  performance  of   most  programs.     71  
  72. 72. The  combinaNon  of  faster  CPUs  and  the  strongly  localized  nature  of  performance   bo`lenecks   72  
  73. 73. makes  code  performance  an  issue  best  le4  un#l  you  can  gather  sta#s#cs  from   realis#c  data  sets     73  
  74. 74. Overall,  the  goal  of  breaking  your  program  into  methods  is  to:     •  communicate  your  intent  clearly  with  your  reader   •  provide  for  future  flexibility   •  set  yourself  up  for  effecNve  performance  tuning  where  necessary     74  
  75. 75. Let’s  look  at  the  pa`erns     75  
  76. 76. Decomposing  Message     How  do  you  invoke  parts  of  a  computaNon?       76  
  77. 77. A  method  is  ge{ng  too  big  and  you  need  to  break  it  into  parts  so  you  can  understand   it  be`er     77  
  78. 78.   AlternaNvely,  you  may  have  noNced  that  two  or  more  methods  have  similar  parts…   78  
  79. 79. …  and  you’d  like  to  put  the  parts  in  a  single  method     79  
  80. 80. How  do  you  invoke  parts  of  a  computaNon?     Send  several  messages  to  ‘self’     80  
  81. 81. To  control  an  acNvity,  the  controller  sends  itself  a  sequence  of  messages     This  is  so  simple.  Why  am  I  telling  you  this?   81  
  82. 82. Because  Smalltalk  code  reveals  a  much  more  aggressive  aItude  towards   decomposing  code  than  other  languages       82  
  83. 83. Most  style  guides  say  “Keep  the  code  for  a  rouNne  on  one  page”.       Most  good  Smalltalk  methods  fit  into  a  few  lines     83  
  84. 84. Certainly  (always)  less  than  10,  and  o4en  (some#mes)    3  or  4       84  
  85. 85. (to  be  fair)  partly  this  is  possible  because  the  abstracNons  Smalltalk  provides  are   higher  level  than  what  other  languages  provide     85  
  86. 86. The  other  reason  I  am  telling  you  about  decomposing  message  is  because  it  has  a   ‘forward’  secNon  that  binds  together  the  other  three  pa`erns  we  are  going  to  look   at.     Once  you  have  decided  to  decompose  a  method,  you:     •  Use  Composed  Method  to  break  the  method  into  pieces   •  Make  each  method  an  IntenNon  Revealing  Method   •  Use  Explaining  Message  to  communicate  intent  separate  from  implementa#on     86  
  87. 87. Ok,  so  we  have  seen  the  ‘Decomposing  Message’  pa`ern.       Now  we  are  going  to  look  at  the  Composed  Method  pa`ern.   87  
  88. 88. As  an  aside,  in  this  interview  (on  InfoQ)  about  ImplementaNon  Pa`erns,  when  Beck  is   asked  which  are  the  central  pa`erns  of  the  book  he  says  that  the  canonical  one  is   composed  method.   88  
  89. 89. Composed  Method     How  do  you  divide  a  program  into  methods?         89  
  90. 90. Programs  need  to  do  more  than  just  instruct  a  computer,  they  need  to  communicate   to  people  as  well.       90  
  91. 91. How  your  program  is  broken  into  methods  (as  well  as  how  big  those  methods  are)…   91  
  92. 92. …this  one  of  the  most  important  decisions  you  will  make  as  you  refine  your  code  so   that  it  communicates  as  clearly  as  possible.     92  
  93. 93. How  do  you  divide  a  program  into  methods?     •  Divide  your  program  into  methods  that  perform  one  idenNfiable  task     •  Keep  all  of  the  operaNons  in  a  method  at  the  same  level  of  abstracNon   •  This  will  naturally  result  in  programs  with  many  small  methods,  each  a  few  lines   long     93  
  94. 94. Example  of  composed  method.     Yes,  it  is  exactly  the  same  example  as  for  Decomposing  Message,  but  that  makes   sense  if  you  think  about  it.   94  
  95. 95. 1.  Divide  your  program  into  methods     that  perform  one  iden#fiable  task       Easier  said  than  done.     In  Clean  Code,  Uncle  Bob  uses  an  alternaNve  expression  of  ‘one  idenNfiable  task’:     FUNCTIONS  SHOULD  DO  ONE  THING.     THEY  SHOULD  DO  IT  WELL.     THEY  SHOULD  DO  IT  ONLY     He  says  “the  problem  with  that  statement  is  that  it  is  hard  to  know  what  “one  thing”   is”     In  another  presentaNon  we’ll  look  at  why  he  says  that.     For  the  rest  of  this  presentaNon  we’ll  just  pretend  that  it  is  simple  to  determine  if  a   method  performs  one  idenNfiable  task.       95  
  96. 96. 2)  Keep  all  of  the  opera#ons  in  a  method     at  the  same  level  of  abstrac#on     Glenn  Vanderburg  (h`ps://twi`er.com/glv)  named  this  SLAP:    Single  Level  of   AbstracNon  Principle     The  following  method  (from  ImplementaNon  Pa`erns)  is  jarring  to  the  reader:     void  compute()  {          input();          flags|=  0x0080;          output();   }     You  can’t  help  asking  yourself:  What  is  that  bit  twiddling  in  there?    What  does  it   mean?     Code  is  easy  to  understand  when  it  flows.               96  
  97. 97. 3)  This  will  naturally  result  in  programs  with  many  small  methods,  each  a  few  lines   long     We  have  looked  at  the  advantages  that  result  from  lots  of  li`le  pieces.     It  is  not  just  simple  minded  performance  tuning  that  can  lead  one  to  believe  that   larger  methods  are  be`er.   97  
  98. 98. Following  the  flow  of  control  in  programs  with  many  small  methods  can  be  difficult     Novice  Smalltalk  programmers  onen  complain  that  they  can’t  figure  out  where  any   “real”  work  is  ge{ng  done.     This  suggests  to  them  that  large  methods  are  best.   98  
  99. 99. But  with  experience  they  understand  that  well  chosen  names  let  you  correctly   assume  the  meaning  of  invoked  code.   99  
  100. 100. The  most  compelling  reason  for  keeping  methods  small  is  the  opportunity  to   communicate  with  intenNon  revealing  method  names.     Which  is  the  name  of  the  next  pa`ern  we  are  going  to  look  at.   100  
  101. 101. So,  we  just  looked  at  Composed  Method.       Now  we  are  going  to  look  at  IntenNon  Revealing  Method  Name   101  
  102. 102. IntenNon  Revealing  Method     What  do  you  name  a  method?     102  
  103. 103. You  have  two  opNons  in  naming  methods     The  first  is  to  name  the  method  aner  how  it  accomplishes  its  task.     Thus,  searching  methods  would  be  called:     Array<<linearSearchFor   Set<<hashedSearchFor   Btree<<treeSearchFor     103  
  104. 104. The  most  important  argument  against  this  style  of  naming  is  that  it  doesn’t   communicate  well.     It  is  not  a  developer’s  goal  to  blurt  out  everything  they  know  about  their  program  as   soon  as  possible.     Unless  the  implementaNon  strategy  is  relevant  to  users,  leave  it  out  of  the  name     The  curious  can  look  at  the  body  of  the  method  to  see  how  it  is  implemented       104  
  105. 105. The  second  opNon  is  to  name  a  method  a4er  what  it  is  supposed  to  accomplish,  and   leave  “how”  to  the  various  method  bodies     This  is  hard  work,  especially  when  you  only  have  a  single  implementaNon     Your  mind  is  filled  with  how  you  are  about  to  accomplish  the  task,  so  it  is  natural  that   the  name  follow  “how”           105  
  106. 106. The  effort  of  moving  the  name  of  methods  from  “how”  to  “what”  is  worth  it,  both   in  the  short  term  and  the  long  term         The  resulNng  code  will  be  easier  to  read  and  understand     106  
  107. 107. What  do  you  name  a  method?     Name  methods  aner  what  they  accomplish  (NOT  how  they  accomplish  it)     107  
  108. 108. Applying  this  to  our  example,  we  would  name  all  three  methods  searchFor     CollecNons>>searchFor     Really  though,  searching  is  a  way  of  implemenNng  a  more  general  concept:  inclusion     Trying  to  name  the  message  aner  this  more  general  “what”  leads  us  to       CollecNons>>includes     108  
  109. 109. The  forward  secNon  of  this  pa`ern  says:     Once  you  name  a  method,  write  its  body  using  Composed  Method     As  onen  with  pa`erns,  they  refer  to  each  other.  This  makes  it  easier  to  express  them,   but  can  make  it  harder  to  understand  them  at  first.   109  
  110. 110. OK,  so  we  have  looked  at  IntenNon  Revealing  Method  Name     And  we  no  look  at  the  last  pa`ern:  Explaining  Message   110  
  111. 111. How  do  you  communicate  your  intent  when  the  implementaNon  is  simple?     111  
  112. 112. Probably  the  most  frustraNng  part  of  learning  Smalltalk     You  see  a  message  like  highlight  and  think:  this  has  to  be  something  interesNng     ParagraphEditor>>highlight:aRectangle   self  reverse:aRectangle     What  is  going  on?  Communica#on.       Most  importantly,  one  line  methods  are  there  to  communicate.     112  
  113. 113. How  do  you  communicate  your  intent  when  the  implementaNon  is  simple?     •  Send  a  message  to  “self”.     •  Name  the  message  so  that  it  communicates  what  is  to  be  done  rather  than  how  it   is  to  be  done.     •  Code  a  simple  method  for  the  message.     113  
  114. 114. Explaining  Messages  are  the  most  extreme  case  of  wri#ng  for  readers  instead  of  the   computer     Two  examples:       CollecNon>>isEmpty   ^self  size  =  0     Number>>reciprocal   ^1  /  self     Explaining  Message  allows  us  to  separate  intenNon  (the  what)    from  implementaNon   (the  how):  the  method  names  tell  us  what,  and  the  method  bodies  tell  us  how.   114  
  115. 115. An  example  from  Fowler’s  Refactoring.     The  methods  in  blue  that  we  have  extracted  are  Explaining  Messages.     TO  DO:  menNon  Fowler’s  concept  of  semanNc  distance  between  the  name  of  a   method  and  its  body.   115  
  116. 116. OK,  so  we  have  no  looked  at  all  four  pa`erns.     So  what  next?         116  
  117. 117. Beck’s  example  of  composed  method  wasn’t  great  (IMHO)…     117  
  118. 118. …so  I  want  to  look  at  a  be`er  example  in  Kerievsky’s  “Refactoring  To  Pa`erns”   118  
  119. 119. Kerievsky  is  the  head  of  Industrial  Logic,  which  runs  intersNng  course  like  the  ones   above.  They  know  their  stuff.   119  
  120. 120. It  takes  some  #me  to  understand  what  the  method  does     But  if  we  apply  Composed  Method….     The  method  now  contains  only  five  lines  of  code.       I  can  rapidly  understand  what  the  method  does  in  ONE  SECOND.       This  is  a  typical  result  of  applying  Composed  Method.     120  
  121. 121. Actually  we  can  look  at  an  intermediate  step  for  a  good  example  of  an  explaining   message.     In  the  code  above,  the  last  line  is  not  at  the  same  level  of  detail  as  the  rest  of  the   method.  We  are  violaNng  the  SLAP.     We  fix  this  by  applying  Explaining  Message,  i.e.  we  extract  the  offending  line  into  its   own  method.  We  are  now  conforming  to  the  SLAP.     121  
  122. 122.   Composed  Method     A  small,  simple  method  that  you  can  understand  in  seconds     I  like  Kerievsky’s  ‘speed’  angle  on  the  composed  pa`ern:  it  is  so  easy  to  understand   that  it  can  be  done  very  quickly.   122  
  123. 123. The  same  angle  again:     You  apply  the  pa`ern  when  you  can’t  rapidly  understand  a  method.     We  just  saw  his  example  of  this  a  couple  of  slides  ago.       123  
  124. 124. IMHO  Beck  and  Kerievsky  both  refrain  from  EXPLICITLY  staNng  one  aspect  o  fwhy  a   composed  method  is  so  easy  to  quickly  read  and  understand  .     They  both  say  (kerievsky  verbaNm,  and  Beck  more  implicitly):     A  Composed  Method's  name  communicates  what  it  does,  while  its  body   communicates  how  it  does  what  it  does.       124  
  125. 125. What  they  don’t  explicitly  say  is  that…     Although  it  is  true  that  Composed  Method  tells  the  reader  ‘how’  it  does  what  it  does   (which  is  usually  what  slows  down  readers)…     it  consists  purely  or  primarily  of  calls  to  methods  with  inten#on  revealing  names…       and  so  it  actually  reveals  only  a  liDle  bit  of  the  ‘how’,  hiding  the  rest  behind  said   calls.     125  
  126. 126. So  composed  method  reveals  implementaNon  (how)  only  a  li`le  bit  at  a  Nme  (which   is  what  makes  reading  and  understanding  composed  methods  so  easy/quick).     I  found  this  fact  menNoned  in  Alan  Shalloway’s  (et  al.)  ‘EssenNal  Skills  For  The  Agile   Developer’.     The  four  pa`erns  we  have  looked  at  are  part  of  what  in  Extreme  Programming  is   called  IntenNonal  Programming.     The  key  organizing  principle  in  (composed)  methods  wri`en  in  the  IntenNonal   Programming  style  is  that  their  body  contains  all  the  steps  (the  what),  but  very  li`le   of  the  actual  implementaNon  (the  how).       What  IntenNonal  Programming  (and  composed  method)  do  is  allow  us  to  separate   the  process  by  which  something  is  done  from  the  actual  accomplishing  of  the  thing.   126  
  127. 127. And  here  is  a  good  example  of  composed  method  from  the  book.     We  can  clearly  see  the  focus  on  the  WHAT,  and  the  minimal  amount  of  HOW  that  the   method  reveals:  this  is  what  makes  the  method  easy  to  quickly  read  and  understand         127  
  128. 128. Back  to  ‘Refactoring  to  Pa`erns’,  to  have  a  quick  look  at  a  few  more  of  Kerievsky’s   interesNng  angles  on  composed  method.   128  
  129. 129. “Do  you  write  lots  of  composed  methods?     I  like  to  think  I  do,  but  I  onen  find  that  I  don't,  at  first.       So  I  have  to  go  back  and  refactor  to  this  paDern.  “     This  is  not  surprising  since  the  thesis  of  the  book  is  that  design  pa`erns  are  not   something  you  apply  up  front,  but  something  that  you  refactor  towards  when  you   find  the  need.     When  code  contains  lots  of  composed  methods  then  it  tends  to  be  easy  to  use  read   and  extend.     129  
  130. 130. Remember  earlier  when  we  saw  Beck’s  thoughts  on  the  typical  length  of  good   Smalltalk  methods?  Always  less  than  10  lines.  SomeNmes  3  or  4  lines     Here  we  see  Kerievsky’s  take  on  this:  rarely  more  than  10  lines.  Usually  about  5.     Largely  in  line  with  Beck  IMHO  when  you  consider  that  Kerievsky  is  dealing  with  Java,   whose  abstracNons  are  lower  level  than  Smalltalk’s   130  
  131. 131. I’ll  conclude  this  look  at  ‘Refactoring  to  Pa`erns’  with  this  thought  of  Kerievsky’s:     When  you  add  up  all  the  Nme  you  and  your  team  spend  trying  to  understand  a   system's  code,  you  can  just  imagine  how  much  more  efficient  and  effecNve  you'll  be  if   the  system  is  composed  of  many  Composed  Methods.           131  
  132. 132. I  think  I  can  safely  say  that  so  far  I  have  engaged  your  visual  channel.  To  improve   retenNon,  allow  me  to  sNmulate  your  auditory  channel  by  playing  part  of  a  poem  on   Composed  Method,  composed  by  Tim  Berglund  (h`ps://twi`er.com/tlberglund)     Play  the  following  from  minute  3  onwards:       http://www.youtube.com/watch?v=3QbheQitF74   132  
  133. 133. 133  
  134. 134. 134  
  135. 135. 135  

×