escape from the spaghetti code jungle
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
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