Change Velocity

The speed and direction of change, e.g., of fragments of code.

ChangeVelocity can guide program organisation. When two pieces of code have similar change velocities, that's a hint that they should be placed in the same module. When the change velocities are different, consider placing them in different modules.

Fragments of code often have similar change velocities if they access a common representation. Every time the representation changes, all the pieces of code that use it must change at once. This is part of the reason we use objects as modules to encapsulate representation. Separating interface from implementation makes sense under this guideline too - the implementation changing more often and thus having a higher ChangeVelocity.

If a class has a stable part and an unstable part, that's a difference in change velocity that suggests moving the stable part to a (possibly abstract) base class. Similarly, if a class has two parts which change equally often but at different times or in different directions (that is to say, for different reasons), then that again suggests refactoring the class.

Sometimes replace "module" with "routine". For example, if one line of a routine is likely to change more often than the rest - perhaps it is the line which creates a new object instance and contains the name of its class - consider moving it to its own routine. Then subclasses can easily effect their change by overriding it. (Sometimes if is worth using an ObjectFactory class, but even if not you should at least use an ObjectFactory method.)


I came across this concept on Usenet many years ago, but I've rarely seen it used since. I find it very useful. It expresses some crucial underlying motivation of object oriented design. Of course, it's therefore blindingly obvious. Comments welcomed. -- DaveHarris
See also:
These are changes of the program. There is another sense of change velocity- you don't want instance variables changing at different rate, or rather that is a sign of potential problems. For example, in a graphics editor you shouldn't keep the figures and the handles in the same collection, because the figures change once a minute or once an hour and the handles change once a second or once a minute.
In a somewhat larger view, you want a system to be able to change fast enough to keep up with the changes in the business (this is also called ImpedanceMismatch)
EditText of this page (last edited September 13, 2002)
FindPage by browsing or searching

This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006