Life cycle and Refactoring Patterns that Support Evolution and Reuse

By: B. Foote, W.F. Opdyke
Published in: PLoPD1
Pages: 239-257

Summary: Software development comprises recurring prototype phases, expansion phases, and consolidation phases. These are patterns for evolving from inheritance hierarchies to aggregations and creating abstract classes.

Url: http://www.laputan.org/lifecycle/Lifecycle.html

Category: Refactoring, Design Process

Pattern: Prototype a First-Pass Design

Pages: 242-244

The initial design of a system should focus on the requirements at hand, with broader applicability as a secondary concern. Get something running quickly to obtain design feedback. Build a prototype. Apply: Nouns in the Specification Imply Objects, Verbs Imply Operations; Build on Existing Objects Using Inheritance; Get it Running Now, Polish It Later; Avoid Premature Generality.

Category: Design Process

• This pattern has the same intent as Prototype [Cockburn98], Prototype [Coplien95b], and Prototypes
• This pattern has a different intent from Prototype [Gamma+95], which is a creational pattern where objects clone themselves.

Pattern: Expand the Initial Prototype

Pages: 244-245

Add code to subclasses to maintain design integrity when changes are made. Apply: Subclass Existing Code Instead of Modifying It; Build on Existing Objects Using Inheritance; Defer Encapsulation for Shared Resources; Avoid Premature Generality; Get It Running Now, Polish It Later.

Category: Design Process

Pattern: Consolidate the Program to Support Evolution and Reuse

Pages: 245-247

As objects evolve, design insights emerge. Refactor objects to reflect these insights: use consistent names; eliminate case analysis; reduce the number of arguments; reduce the size of methods; class hierarchies should be deep and narrow; the top of the class hierarchy should be abstract; minimize access to variables; subclasses should be specializations; split large classes; factor implementation differences into subcomponents; separate methods that do not communicate; send messages to components instead of to self; reduce implicit parameter passing.

Pattern: Evolve Aggregations from Inheritance Hierarchies

Pages: 248-252

Class hierarchies developed in early phases are often functional but neither elegant nor reusable. Convert inheritance to aggregation by factoring parts of a class into a new component class.

Pattern: Create Abstract Superclass

Pages: 252-254

Clean up inheritance hierarchies by defining abstract classes that capture behavior common to one or more classes.

• This pattern presents the same solution as Abstract Class