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
invarients - 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 Invariants aren't always constants[?].
The assumptions which become ingrained into a program are
structural, philosophical, and intellectuatal 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 horriable as Code momentum. By definition, huge amounts
of search and alteration must be done manually - by hand -
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 - datastructures must match reality. Understand the relationships in the data and the code will follow.
- Abstract root classes - don't write implementations without first creating a separate interface describing all future implementations, of which the first implemenation is only one possibility. Talk about classes in terms of their abstract type to avoid hardcoding the program to one perticular implementation of a given fascility.
- 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[?],
God object[?], and
No sex until marriage[?].
- 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 solutation, 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 flexiability in changing their interface, atleast until things stableize. 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 ModelViewController.
- Currying concept, Application generator - even the stickyist Cut and paste programming messes have solutions. These two concepts support the idea of OnceAndOnlyOnce.
- 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: