Escape from the Spaghetti Code Jungle

1. Escape from the Spaghetti Code Jungle Brian Foote University of Illinois at Urbana-Champaign 17 February 1998 SOOUG Winter ‘98

2. UIUC Patterns GroupRalph Johnson’s Group • Smalltalk • Objects • Frameworks • Components • Refactoring • Evolution • Patterns

3. Our Perspective • Objects, Patterns, Frameworks, and Refactoring really do work, and can lead to the production of better, more durable, more reusable code • To achieve this requires a commitment to tools, architecture, and software evolution, and to people with superior technical skills and domain insight

4. Big Ball of Mud • The de-facto standard software architecture • Why is the gap between what we preach and what we practice so large?

5. Where does Mud Come From • Throwaway Code • Legacy Mush • Urban Sprawl • Slash and Burn Tactics • Merciless Deadlines • Sheer Neglect

6. Silver Buckshot • Objects • Frameworks • Patterns • Architecture • Process/Organization • Tools

7. Objects • The revolution is over, and objects won • O-O Programming has become Programming • O-O Languages set the stage for the evolution of O-O Frameworks and Components • O-O Reuse works, but is not a panacea

8. Frameworks • An Object-OrientedFramework is a collection of cooperating classes that together define a generic or template solution to a family of domain specific requirements. • 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. • Frameworks embody design insight

9. Notables on Frameworks • Interface design and functional factoring constitute the key intellectual content of software and are far more difficult to create or recreate than code • L. Peter Deutsch • A framework is the design for an application or subsystem • A set of abstract classes and the way objects in those classes collaborate • Ralph E. Johnson

10. Framework Examples • Smalltalk-80 Model/View/Controller (MVC) • MacApp • InterViews ET++ OWL MFC • AFC AWT JFC IFC • Taligent Frameworks • Choices • Battery Simulation • Accounts

11. Object-Oriented Frameworks have made the GUI Revolution Possible • MVC begot • Lisa Toolkit begot • Macintosh Toolbox begot • MacApp begot • Interviews/ET++ begot • OWL/MFC begot AWT, etc. • The analysis and evolution underlying MVC • now permeates the industry

12. Patterns • What’s New Here is that Nothing is New Here • Patterns are about what works • Patterns give us a way to talk about what works • Patterns distill experience • Patterns give us a concise design vocabulary

13. Why Patterns • People do not design from first principles • People design by reusing things they’ve seen before • Same techniques appear over and over • Software industry needs to document what we do

14. Alexander on Patterns • Patterns in solutions come from patterns in problems. • "A pattern is a solution to a problem in a context." • "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." • Christopher Alexander -- A Pattern Language

15. The Gang of Four • Design Patterns: Elements of Reusable Object-Oriented Software • Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides • Addison Wesley, 1995 • A landmark book that changed the way programmers think about building object-oriented programs

16. Composite • Context: • Developing OO software • Problem: • Complex part-whole hierarchy has lots of similar classes. • Example: document, chapter, section, paragraph. • Forces • • simplicity -- treat composition of parts like a part • • power -- create new kind of part by composing existing ones • • safety -- no special cases, treat everything the same

17. Composite • Idea: make abstract "component" class. • Alternative 1: every component has a (possibly empty) set of components. Component Children Chapter Paragraph ... Problem: many components have no components

18. Composite Component Container Children Leaf Composite • Composite and Component have the exact same interface. • • interface for enumerating children • • Component implements Children() by returning empty set • • interface for adding/removing children?

19. Bird on Patterns • Learn the patterns and then forget ‘em • -- Charlie Parker

20. Lehman and Belady • Lehman and Belady have studied the history of successive • releases in a large operating system. They find that the • total number of modules increases linearly with release number, • but that the number of modules affected increases exponentially with release number. All repairs tend to destroy the structure • to increase the entropy and disorder of the system. • Less and less effort is spent fixing original design flaws; • more and more is spent on fixing flaws introduced in earlier fixes. • As time passes, the system becomes less and less well ordered...

21. Entropy • ...Systems program building is an entropy decreasing process, • hence inherently metastable. • Program maintenance is an entropy increasing process, • and even its most skillful execution only • delays the subsidence of the system into • unfixable obsolescence... • Maintenance, it would seem, is like fixing holes in a • failing dike. Eventually it fails, and must be • rebuilt. Only then are lessons learned during • its tenure exploited

22. Iteration • Consider these two statements: • Iteration considered harmful • "Iteration" considered harmful • "Iteration" inspires visions of wheelsspinning or dogschasing their tails, or of money spinning down the drain... • Most researchers who have examined where Reusable Objectscomefrom have observed that they are the result of a highly iterative process

23. Software Tectonics • Reconstruction • Major Upheaval • Throw it away • Incremental Change • Evolution • Piecemeal Growth

24. Throwaway Code • Sometimes this is the right approach • There is the danger that such code will take on a life of its own

25. Reconstruction • Atlanta’s Fulton County Stadium was built in 1966 and razed in 1997. • Two single purpose stadia, with skyboxes, are replacing it

26. Sweep It Under the Rug • You may not know how to get rid of a problem, but at least you can cordon it off...

27. Piecemeal Growth • Mir was designed to accommodate maintenance and growth • Core1986 • Kvant 11987 • Kvant 21989 • Kristall1990 • Spekter 1995 • Docking1995 • Priroda1996

28. White-Box vs. Black-Box Frameworks • White-Box Frameworks • Are extended primarily via inheritance • Each method must abide by • the internal conventions of its superclasses • Are informally organized internally, yet encapsulated • "Permissive" scope rules allow structure to undergo experimentation • Are characteristic of the early, exploratory phases of a framework's • evolution

29. Black-Box Frameworks • As a framework evolves • portions of the framework emerge as distinct components • Communication is in conformity with the components external protocol • Are indicative of a better, more mature understanding • of the structure of a system • Are a goal toward which framework designers should aspire

30. The Fractal Model • Reusable object-oriented abstract classes, components and frameworks have lifecyles of their own that are distinct from those of the applications that incubate them • Objects evolvewithin and beyond the applications that spawned them • Structureemerges as objectsevolve • Because the pattern in which they evolve is similar at each level, the overall pattern can be thought of as a fractal curve • Opportunistic, as opposed to driven by Risk

31. Initial Design (Prototype) Phase • Usually a prototype (of sorts) • Informally structured • Employs expedient "code borrowing" • Constitutes a first pass at design • General design opportunities should be anticipated, where possible • Expedient design should never be mistaken for good design

32. Exploratory (Expansionary) Phase • Occurs when a design is successful • Frequently occurs during the "perfective" maintenance phase • Characterized by the spawning of a number of specialized • variations on the original theme • Broad, shallow class hierarchies may develop • There is a risk of "mid-life" generality loss • These may be somewhat informally organized • A "white-box" phase

33. Design Consolidation (Generalization) Phase • Where entropyreduction gets done • Class hierarchy is reorganized and refactored • Abstract classes that reflect structural regularities in the system emerge • Hierarchy comes to reflect the way you'd like to tell people you got it there • Refactoring at this point in a system's evolution allows the • designer to exploit the insights available from having specialized a design to suit a number of applications • Hindsight, which is now available, can be brought to bear on the redesign • A "black-box" phase

34. Refactoring • Refactoring is the engine of Consolidation • Refactorings are programtransformations that preserve program semantics, while improving structure • Refactoring has traditionally been done by hand, but tools are starting to emerge • Languages differ significantly in the degree to which they support refactoring

35. Refactorings • Behavior Preserving Program Transformations • Move Method to Component • Promote Method to Superclass • Rename Instance Variable

36. Maximal Diversity is Early • From Gould, Gilinsky, and German • Asymmetry of Lineages and the Direction of Evolutionary Time • Evolutionary groups generally concentrate diversity during their early histories • Any taxonomic group builds to maximum diversity, and declines to extinction • They suggest that their documented temporal asymettry • may display a fractal character of self similarity at all scales • [Early] asymmetry arises when an initial emptiness permits unusual opportunity for diversification

37. Pottery and Headstones • Such patterns have been noted in the evolution of Egyptian pottery designs, New England headstones, and 19th century gas lanterns • ...the structural principles that fashion the molds • and set the constraints upon the pathways of change • be may more abstract, and therefore more common • to a broad range of disciplines wedded to • differing immediate mechanisms

38. Architect-Builder • Architect also Builds -- Coplien • Deploy People along the Grain of the Domain • Intra- vs. Inter-cranial communication • Response to Le Corbusier

39. Unfolding • Step-by-Step Adaptation • Feedback • Unpredictability • Awareness of the Whole

40. Carriages and Locomotives • Locomotives were unprecedented, and evolved from crude forms driven by primary design considerations • Carriages evolved from stagecoach designs, and began as stagecoach frames on rolling stock

41. Implications • Design pervades the lifecycle • Design pervades the organization • Emphasis is not so much on single applications as on developing the software infrastructure for solving a range of application requirements • If hindsight is so valuable, the perhaps current programmer deployment practices are backwards • Skilled designers may be most valuable during the design consolidation phase • Perhaps this perspective can lead to a • gentrification of maintenance

42. Conclusions • Frameworks embody architecture • Patterns communicate design insight • Refactoring facilitates evolution • Architecture emerges as a domain is explored • Design pervades the lifecycle, and the organization • Tools can help. Better Tools are on the way

43. Twain on Domain Knowledge • “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?” • “On my honor, you’ve got to know them better than any man did know the shapes of the halls in his own house.” • “I wish I was dead!”

44. Draining the Swamp • You can escape from the Spaghetti Code Jungle • Indeed you can transform the landscape • The key is not some magic bullet, but a long-term commitment to architecture, and to cultivating and refining quality artifacts for your domain

45. Contact Information • Brian Foote • Dept. of Computer Science • 3253 DCL • 1304 W. Springfield • Urbana, IL 61801 • (217) 328-3523 • http://www.laputan.org • foote@cs.uiuc.edu