Escape from the Spaghetti Code Jungle

Brian FooteUniversity of Illinois

at Urbana-Champaign

17 February 1998

SOOUG Winter ‘98

UIUC Patterns GroupRalph 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 MudThe 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 FrameworksInterface 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 ExamplesSmalltalk-80 Model/View/Controller (MVC)

MacApp

InterViews ET++ OWL MFC

AFC 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

MacApp 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

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

CompositeIdea: make abstract "component" class.

Alternative 1: every component has a (possibly empty) set of components.

Component

Children

ParagraphChapter ...

Problem: many components have no components

CompositeComponent

ContainerChildren

CompositeLeaf

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

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

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

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

ImplicationsDesign 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 FooteDept. of Computer Science

3253 DCL

1304 W. Springfield

Urbana, IL 61801

(217) 328-3523

http://www.laputan.org

foote@cs.uiuc.edu