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