Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Escape from the Spaghetti Code Jungle Brian Foote University of Illinois at Urbana-Champaign 17 February 1998 SOOUG Winter ‘98
  2. 2. UIUC Patterns Group Ralph Johnson’s Group <ul><li>Smalltalk </li></ul><ul><li>Objects </li></ul><ul><li>Frameworks </li></ul><ul><li>Components </li></ul><ul><li>Refactoring </li></ul><ul><li>Evolution </li></ul><ul><li>Patterns </li></ul>
  3. 3. Our Perspective <ul><li>Objects, Patterns, Frameworks, and Refactoring really do work, and can lead to the production of better, more durable, more reusable code </li></ul><ul><li>To achieve this requires a commitment to tools, architecture, and software evolution, and to people with superior technical skills and domain insight </li></ul>
  4. 4. Big Ball of Mud <ul><li>The de-facto standard software architecture </li></ul><ul><li>Why is the gap between what we preach and what we practice so large? </li></ul>
  5. 5. Where does Mud Come From <ul><li>Throwaway Code </li></ul><ul><li>Legacy Mush </li></ul><ul><li>Urban Sprawl </li></ul><ul><li>Slash and Burn Tactics </li></ul><ul><li>Merciless Deadlines </li></ul><ul><li>Sheer Neglect </li></ul>
  6. 6. Silver Buckshot <ul><li>Objects </li></ul><ul><li>Frameworks </li></ul><ul><li>Patterns </li></ul><ul><li>Architecture </li></ul><ul><li>Process/Organization </li></ul><ul><li>Tools </li></ul>
  7. 7. Objects <ul><li>The revolution is over, and objects won </li></ul><ul><li>O-O Programming has become Programming </li></ul><ul><li>O-O Languages set the stage for the evolution of O-O Frameworks and Components </li></ul><ul><li>O-O Reuse works, but is not a panacea </li></ul>
  8. 8. Frameworks <ul><li>An Object-Oriented Framework is a collection of cooperating classes that together define a generic or template solution to a family of domain specific requirements. </li></ul><ul><li>Frameworks are often characterized by an inversion of control in which the framework plays the role of a main program in coordinating and sequencing application activity. </li></ul><ul><li>Frameworks embody design insight </li></ul>
  9. 9. Notables on Frameworks <ul><li>Interface design and functional factoring constitute the key intellectual content of software and are far more difficult to create or recreate than code </li></ul><ul><li>L. Peter Deutsch </li></ul><ul><li>A framework is the design for an application or subsystem </li></ul><ul><li>A set of abstract classes and the way objects in those classes collaborate </li></ul><ul><li>Ralph E. Johnson </li></ul>
  10. 10. Framework Examples <ul><li>Smalltalk-80 Model/View/Controller (MVC) </li></ul><ul><li>MacApp </li></ul><ul><li>InterViews ET++ OWL MFC </li></ul><ul><li>AFC AWT JFC IFC </li></ul><ul><li>Taligent Frameworks </li></ul><ul><li>Choices </li></ul><ul><li>Battery Simulation </li></ul><ul><li>Accounts </li></ul>
  11. 11. Object-Oriented Frameworks have made the GUI Revolution Possible <ul><li>MVC begot </li></ul><ul><li>Lisa Toolkit begot </li></ul><ul><li>Macintosh Toolbox begot </li></ul><ul><li>MacApp begot </li></ul><ul><li>Interviews/ET++ begot </li></ul><ul><li>OWL/MFC begot AWT, etc. </li></ul><ul><li>The analysis and evolution underlying MVC </li></ul><ul><li>now permeates the industry </li></ul>
  12. 12. Patterns <ul><li>What’s New Here is that Nothing is New Here </li></ul><ul><li>Patterns are about what works </li></ul><ul><li>Patterns give us a way to talk about what works </li></ul><ul><li>Patterns distill experience </li></ul><ul><li>Patterns give us a concise design vocabulary </li></ul>
  13. 13. Why Patterns <ul><li>People do not design from first principles </li></ul><ul><li>People design by reusing things they’ve seen before </li></ul><ul><li>Same techniques appear over and over </li></ul><ul><li>Software industry needs to document what we do </li></ul>
  14. 14. Alexander on Patterns <ul><li>Patterns in solutions come from patterns in problems. </li></ul><ul><li>&quot;A pattern is a solution to a problem in a context.&quot; </li></ul><ul><li>&quot;Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.&quot; </li></ul><ul><li>Christopher Alexander -- A Pattern Language </li></ul>
  15. 15. The Gang of Four <ul><li>Design Patterns : Elements of Reusable Object-Oriented Software </li></ul><ul><li>Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides </li></ul><ul><li>Addison Wesley, 1995 </li></ul><ul><li>A landmark book that changed the way programmers think about building object-oriented programs </li></ul>
  16. 16. Composite <ul><li>Context: </li></ul><ul><ul><li>Developing OO software </li></ul></ul><ul><li>Problem: </li></ul><ul><ul><li>Complex part-whole hierarchy has lots of similar classes. </li></ul></ul><ul><ul><ul><li>Example: document, chapter, section, paragraph. </li></ul></ul></ul><ul><li>Forces </li></ul><ul><ul><li>• simplicity -- treat composition of parts like a part </li></ul></ul><ul><ul><li>• power -- create new kind of part by composing existing ones </li></ul></ul><ul><ul><li>• safety -- no special cases, treat everything the same </li></ul></ul>
  17. 17. Composite Idea: make abstract &quot;component&quot; class. Alternative 1: every component has a (possibly empty) set of components. Component Children Paragraph Chapter ... Problem: many components have no components
  18. 18. Composite Component Container Children Composite Leaf <ul><li>Composite and Component have the exact same interface. </li></ul><ul><ul><li>• interface for enumerating children </li></ul></ul><ul><ul><li>• Component implements Children() by returning empty set </li></ul></ul><ul><ul><li>• interface for adding/removing children? </li></ul></ul>
  19. 19. Bird on Patterns <ul><li>Learn the patterns and then forget ‘em </li></ul><ul><li>-- Charlie Parker </li></ul>
  20. 20. Lehman and Belady <ul><li>Lehman and Belady have studied the history of successive </li></ul><ul><li>releases in a large operating system. They find that the </li></ul><ul><li>total number of modules increases linearly with release number, </li></ul><ul><li>but that the number of modules affected increases exponentially with release number. All repairs tend to destroy the structure </li></ul><ul><li>to increase the entropy and disorder of the system. </li></ul><ul><li>Less and less effort is spent fixing original design flaws; </li></ul><ul><li>more and more is spent on fixing flaws introduced in earlier fixes. </li></ul><ul><li>As time passes, the system becomes less and less well ordered... </li></ul>
  21. 21. Entropy <ul><li>...Systems program building is an entropy decreasing process, </li></ul><ul><li>hence inherently metastable. </li></ul><ul><li>Program maintenance is an entropy increasing process, </li></ul><ul><li>and even its most skillful execution only </li></ul><ul><li>delays the subsidence of the system into </li></ul><ul><li>unfixable obsolescence... </li></ul><ul><li>Maintenance, it would seem, is like fixing holes in a </li></ul><ul><li>failing dike. Eventually it fails, and must be </li></ul><ul><li>rebuilt. Only then are lessons learned during </li></ul><ul><li>its tenure exploited </li></ul>
  22. 22. Iteration <ul><li>Consider these two statements: </li></ul><ul><li>Iteration considered harmful </li></ul><ul><li>&quot;Iteration&quot; considered harmful </li></ul><ul><li>&quot;Iteration&quot; inspires visions of wheels spinning or dogs chasing their tails , or of money spinning down the drain ... </li></ul><ul><li>Most researchers who have examined where Reusable Objects come from have observed that they are the result of a highly iterative process </li></ul>
  23. 23. Software Tectonics <ul><li>Reconstruction </li></ul><ul><li>Major Upheaval </li></ul><ul><li>Throw it away </li></ul><ul><li>Incremental Change </li></ul><ul><li>Evolution </li></ul><ul><li>Piecemeal Growth </li></ul>
  24. 24. Throwaway Code <ul><li>Sometimes this is the right approach </li></ul><ul><li>There is the danger that such code will take on a life of its own </li></ul>
  25. 25. Reconstruction <ul><li>Atlanta’s Fulton County Stadium was built in 1966 and razed in 1997. </li></ul><ul><li>Two single purpose stadia, with skyboxes, are replacing it </li></ul>
  26. 26. Sweep It Under the Rug <ul><li>You may not know how to get rid of a problem, but at least you can cordon it off... </li></ul>
  27. 27. Piecemeal Growth <ul><li>Mir was designed to accommodate maintenance and growth </li></ul><ul><li>Core 1986 </li></ul><ul><li>Kvant 1 1987 </li></ul><ul><li>Kvant 2 1989 </li></ul><ul><li>Kristall 1990 </li></ul><ul><li>Spekter 1995 </li></ul><ul><li>Docking 1995 </li></ul><ul><li>Priroda 1996 </li></ul>
  28. 28. White-Box vs. Black-Box Frameworks <ul><li>White-Box Frameworks </li></ul><ul><li>Are extended primarily via inheritance </li></ul><ul><li>Each method must abide by </li></ul><ul><li>the internal conventions of its superclasses </li></ul><ul><li>Are informally organized internally, yet encapsulated </li></ul><ul><li>&quot;Permissive&quot; scope rules allow structure to undergo experimentation </li></ul><ul><li>Are characteristic of the early , exploratory phases of a framework's </li></ul><ul><li>evolution </li></ul>
  29. 29. Black-Box Frameworks <ul><li>As a framework evolves </li></ul><ul><li>portions of the framework emerge as distinct components </li></ul><ul><li>Communication is in conformity with the components external protocol </li></ul><ul><li>Are indicative of a better, more mature understanding </li></ul><ul><li>of the structure of a system </li></ul><ul><li>Are a goal toward which framework designers should aspire </li></ul>
  30. 30. The Fractal Model <ul><li>Reusable object-oriented abstract classes, components and frameworks have lifecyles of their own that are distinct from those of the applications that incubate them </li></ul><ul><li>Objects evolve within and beyond the applications that spawned them </li></ul><ul><li>Structure emerges as objects evolve </li></ul><ul><li>Because the pattern in which they evolve is similar at each level, the overall pattern can be thought of as a fractal curve </li></ul><ul><li>Opportunistic , as opposed to driven by Risk </li></ul>
  31. 31. Initial Design (Prototype) Phase <ul><li>Usually a prototype (of sorts) </li></ul><ul><li>Informally structured </li></ul><ul><li>Employs expedient &quot;code borrowing&quot; </li></ul><ul><li>Constitutes a first pass at design </li></ul><ul><li>General design opportunities should be anticipated, where possible </li></ul><ul><li>Expedient design should never be mistaken for good design </li></ul>
  32. 32. Exploratory (Expansionary) Phase <ul><li>Occurs when a design is successful </li></ul><ul><li>Frequently occurs during the &quot;perfective&quot; maintenance phase </li></ul><ul><li>Characterized by the spawning of a number of specialized </li></ul><ul><li>variations on the original theme </li></ul><ul><li>Broad, shallow class hierarchies may develop </li></ul><ul><li>There is a risk of &quot;mid-life&quot; generality loss </li></ul><ul><li>These may be somewhat informally organized </li></ul><ul><li>A &quot;white-box&quot; phase </li></ul>
  33. 33. Design Consolidation (Generalization) Phase <ul><li>Where entropy reduction gets done </li></ul><ul><li>Class hierarchy is reorganized and refactored </li></ul><ul><li>Abstract classes that reflect structural regularities in the system emerge </li></ul><ul><li>Hierarchy comes to reflect the way you'd like to tell people you got it there </li></ul><ul><li>Refactoring at this point in a system's evolution allows the </li></ul><ul><li>designer to exploit the insights available from having specialized a design to suit a number of applications </li></ul><ul><li>Hindsight , which is now available, can be brought to bear on the redesign </li></ul><ul><li>A &quot;black-box&quot; phase </li></ul>
  34. 34. Refactoring <ul><li>Refactoring is the engine of Consolidation </li></ul><ul><li>Refactorings are program transformations that preserve program semantics, while improving structure </li></ul><ul><li>Refactoring has traditionally been done by hand, but tools are starting to emerge </li></ul><ul><li>Languages differ significantly in the degree to which they support refactoring </li></ul>
  35. 35. Refactorings <ul><li>Behavior Preserving Program Transformations </li></ul><ul><li>Move Method to Component </li></ul><ul><li>Promote Method to Superclass </li></ul><ul><li>Rename Instance Variable </li></ul>
  36. 36. Maximal Diversity is Early <ul><li>From Gould, Gilinsky, and German </li></ul><ul><li>Asymmetry of Lineages and the Direction of Evolutionary Time </li></ul><ul><li>Evolutionary groups generally concentrate diversity during their early histories </li></ul><ul><li>Any taxonomic group builds to maximum diversity, and declines to extinction </li></ul><ul><li>They suggest that their documented temporal asymettry </li></ul><ul><li>may display a fractal character of self similarity at all scales </li></ul><ul><li>[Early] asymmetry arises when an initial emptiness permits unusual opportunity for diversification </li></ul>
  37. 37. Pottery and Headstones <ul><li>Such patterns have been noted in the evolution of Egyptian pottery designs, New England headstones, and 19th century gas lanterns </li></ul><ul><li>...the structural principles that fashion the molds </li></ul><ul><li>and set the constraints upon the pathways of change </li></ul><ul><li>be may more abstract, and therefore more common </li></ul><ul><li>to a broad range of disciplines wedded to </li></ul><ul><li>differing immediate mechanisms </li></ul>
  38. 38. Architect-Builder <ul><li>Architect also Builds -- Coplien </li></ul><ul><li>Deploy People along the Grain of the Domain </li></ul><ul><li>Intra- vs. Inter-cranial communication </li></ul><ul><li>Response to Le Corbusier </li></ul>
  39. 39. Unfolding <ul><li>Step-by-Step Adaptation </li></ul><ul><li>Feedback </li></ul><ul><li>Unpredictability </li></ul><ul><li>Awareness of the Whole </li></ul>
  40. 40. Carriages and Locomotives <ul><li>Locomotives were unprecedented, and evolved from crude forms driven by primary design considerations </li></ul><ul><li>Carriages evolved from stagecoach designs, and began as stagecoach frames on rolling stock </li></ul>
  41. 41. Implications <ul><li>Design pervades the lifecycle </li></ul><ul><li>Design pervades the organization </li></ul><ul><li>Emphasis is not so much on single applications as on developing the software infrastructure for solving a range of application requirements </li></ul><ul><li>If hindsight is so valuable , the perhaps current programmer deployment practices are backwards </li></ul><ul><li>Skilled designers may be most valuable during the design consolidation phase </li></ul><ul><li>Perhaps this perspective can lead to a </li></ul><ul><li>gentrification of maintenance </li></ul>
  42. 42. Conclusions <ul><li>Frameworks embody architecture </li></ul><ul><li>Patterns communicate design insight </li></ul><ul><li>Refactoring facilitates evolution </li></ul><ul><li>Architecture emerges as a domain is explored </li></ul><ul><li>Design pervades the lifecycle , and the organization </li></ul><ul><li>Tools can help. Better Tools are on the way </li></ul>
  43. 43. Twain on Domain Knowledge <ul><li>“ Do you mean to say I’ve got to know all the million trifling variations of shape in the banks of of this interminable river as well as I know the shape of the front hall at home?” </li></ul><ul><li>“ On my honor, you’ve got to know them better than any man did know the shapes of the halls in his own house.” </li></ul><ul><li>“ I wish I was dead!” </li></ul>
  44. 44. Draining the Swamp <ul><li>You can escape from the Spaghetti Code Jungle </li></ul><ul><li>Indeed you can transform the landscape </li></ul><ul><li>The key is not some magic bullet, but a long-term commitment to architecture , and to cultivating and refining quality artifacts for your domain </li></ul>
  45. 45. Contact Information <ul><li>Brian Foote </li></ul><ul><li>Dept. of Computer Science </li></ul><ul><li>3253 DCL </li></ul><ul><li>1304 W. Springfield </li></ul><ul><li>Urbana, IL 61801 </li></ul><ul><li>(217) 328-3523 </li></ul><ul><li>http://www.laputan.org </li></ul><ul><li>[email_address] </li></ul>