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 Invariants aren't always constants. 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 root classes - 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 , 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 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
• Planning is NP complete
• Bottom-up design
• Cross-sectional refactoring
• Currying concept
• Application generator
• Once and only once