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
----
Is there any tool support to visualize the change velocity and direction of different pieces of code?
----
See also:
	* CodeSmell''''''s.
	* the paper on Granularity at http://www.objectmentor.com, where Robert Martin covered the concept.
	* the paper on the CommonClosurePrinciple.
----
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)

----
CategoryChange