Escape from the Spaghetti Code Jungle Brian Foote

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

UIUC Patterns Group Ralph Johnson’s Group • • Smalltalk Objects Frameworks Components Refactoring Evolution Patterns

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

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

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

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

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

Frameworks • 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. • 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

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

Framework Examples Smalltalk-80 Model/View/Controller (MVC) Mac. App Inter. Views ET++ OWL MFC AWT JFC IFC Taligent Frameworks Choices Battery Simulation Accounts

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

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

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

Alexander on 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

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

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

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

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

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

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. . .

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

Iteration Consider these two statements: Iteration considered harmful "Iteration" inspires visions of wheels spinning or dogs chasing their tails, or of money spinning down the drain. . . Most researchers who have examined where Reusable Objects come from have observed that they are the result of a highly iterative process

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

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

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

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

Piecemeal Growth Mir was designed to accommodate maintenance and growth • • Core 1986 Kvant 1 1987 Kvant 2 1989 Kristall 1990 Spekter 1995 Docking 1995 Priroda 1996

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

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

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 evolve within and beyond the applications that spawned them • Structure emerges as objects evolve • 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

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

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

Design Consolidation (Generalization) Phase Where entropy reduction 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

Refactoring is the engine of Consolidation Refactorings are program transformations 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

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

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

Pottery and Headstones Such patterns have been noted in the evolution of Egyptian pottery designs, New England headstones, and 19 th 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

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

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

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

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

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

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!”

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

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