Transcript Escape from the Spaghetti Code Jungle
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) 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
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 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 drain
...
spinning
down
the 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 own that are
distinct lifecyles
of their from those of the applications that incubate them • Objects
evolve
within and beyond the
applications
that spawned them • •
Structure emerges
a
fractal curve
as
objects evolve
• Because the
pattern
in which they evolve is
similar
at each level, the overall pattern can be thought of as
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 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 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
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
explored emerges as a
domain
is
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