Adapt to adapt is a condition seen in practice of computer programming.
The more a program changes, the more tolerant of change it will become.
It adapts to adapt. Refactoring achieves this. A program must have
invariants - assumptions that it can make about the world and what
is required of itself - and they aren t always values that can be
set in a configuration file: see Invariant.
The assumptions which become ingrained into a program are
structural, philosophical, and intellectual suppositions of
what the program ought to do. These assumptions create
code momentum - a commitment that becomes harder and harder to
uncommit to as the program accelerates headlong in a given
direction. No other degenerate lapse of code sense is as
uniquely horrible as code momentum. By definition, huge amounts
of search and alteration must be done manually to undo the damage.
These rules cover key elements of refactoring and design related to
code momentum.
Adapt to adapt checklist:
Objects and relational database systems - data structures must match reality. Understand the relationships in the data and the code will follow.
Abstract class - don t write implementations without first creating a separate interface describing all future implementations, of which the first implementation is only one possibility. Talk about classes in terms of their abstract type to avoid hardcoding the program to one particular implementation of a given facility.
Whole object - the more objects exist in the system, the more chances you have to return objects to satisfy queries and standardize object types as input to methods. See also Inner classes and God object.
Law of Demeter - don t ask strangers in far away lands for help when you can ask cohorts and collaborates. Make requests that get you one step closer to the solution, rather than try to nail it dead on. This limits interdependency between distant parts of the system: local changes only affect near by code.
Facade pattern - create a demilitarized zone between developers to allow each developer flexibility in changing their interface, at least until things stabilize. This creates some turf that no one owns but anyone can dump code into in attempt to meet the interface requirements without making a mess of their own area. See also Model-view-controller.
Currying concept, Application generator - even the stickiest Cut and paste programming messes have solutions. These two concepts support the idea of Once-and-only-once.
CPAN - Built the parts that can be tested first - that is, the parts that don t depend on non-existent code. Looking at this liberally, it could mean to create the nuts and bolts, or it could mean to create an articulated skeleton. Considering CPAN s offers when designing the project is Bottom-up design at its best.
The article is originally from Perl Design Patterns Book.
=See also=
Design pattern (computer science)
Planning is NP complete
Bottom-up design
Cross-sectional refactoring
Currying concept
Application generator
Once and only once