06.12.09
How difficult is it to change your code?
Change happens. We’re not perfect. We don’t know everything. We invariably learn something about the project we’re doing while we’re doing it.
So, code that can easily be changed is better than code that can’t be changed. But how do we know how easy it is to change code?
Difficulty of changing code is best measured at the class/interface level.
If you have a lot of classes that are each easily changed, you will be able to change your code easily. If you have a few classes that are each difficult to change, it will be difficult to change your code. Even if the total work done is the same.
The primary measure of difficulty of changing code is the number of consumers it has.
The more things that know about your code, the harder it is to change. This is a reason why the universally-loved concept of “the one place that does all X’ almost always fails.
It is easier to change an interface that has one consumer than one with three consumers. It is easier to change an interface with three consumers than one with twenty consumers. And if you have one hundred consumers, forget about it.
By consumers, I do not necessarily refer to applications or individuals, rather I refer to classes that refer to any individual class.
It’s easier to change internal code than public-facing code.
This is a restatement of the first point. Published, public-facing code has an infinite number of consumers, making it nearly impossible to change.
The more implementation details you expose, the harder it is to change your code.
Public-facing code should, as much as possible, not leak implementation details. It should reflect the user-facing concepts that are being exposed, and not the implementation details of those concepts.
Not exposing raw types is a good way to do this as well. If you have a user ID that’s an int right now, it may be somewhat painful to change it to a long later. However, if you wrap the int in a UserID class, changing it to use a long or even a GUID will become much, much easier.
The more scenarios you support, the harder it is to change
If you support a large number of scenarios, it is almost inevitable that assumptions needed for one will spill over into others.
The more well-defined your code is, the easier it is to change
If your code has well-defined inputs and outputs, and doesn’t have side effects, it is much easier to change. While the public entry points may remain difficult to change if they have many consumers, any internal details can be changed arbitrarily, and the correctness of the final code can be verified.
On the other hand, if the behavior of the code is not well-defined, then changing it can become extremely difficult, as consumers may be relying upon existing behavior that is either in error, undocumented (and so likely to change if you touch the implementation), or simply a side effect of the “real” work being done.