Ok, this first appeared on the corporate TWiki last November, but now for the masses…
Reluctance to Add New Classes
Or, How More Can Be Simpler
When we’re using dependency breaking techniques to make code testable, the solution sometimes involves breaking a multipurpose monster routine into multiple classes. Others may feel a reluctance to such a design. The question “Isn’t this adding complexity to the system?” may be thought, even if it is not spoken. It’s a fair question. If someone says they’re going to simplify the system by adding several more source files, one would hope they can demonstrate how their proposal is simpler. Let’s see if we can do it, at least in concept.
First, a graphical representation of the existing routine:
Several hundred lines of code, doing a hundred different things. It’s very difficult to test pieces of this; mostly we have to set everything up, call in at the top, and try our best to detect, of the many changes the routine may make to the system, which ones are correct and which ones may be bugs (it’s very easy to get this wrong, even when we’ve been in this area of the system several times). We see this style of code a lot in the system, so it looks familiar.
Now, when we speak of breaking the monster routine into multiple classes, this is what we mean:
There are now more classes in the system, but each one has a single responsibility. Because each class has a more focused purpose…
- Its name can be more descriptive so you can tell what the class is supposed to do
- It’s easier to spot things that look like they don’t belong – potential bugs
This separating of concerns also helps toward being able to thoroughly test each class individually to weed out bugs before putting all the components together in an integration test. This is more efficient than waiting until putting all the components together to test them.
With our heads full of happily dancing visions of all these benefits, we sometimes fail to adequately communicate our vision to those around us. When we do this, we may leave them seeing a very different picture:
Aaaaah! Instead of one horribly difficult routine to understand, we now have five more horribly difficult source files to understand. Why would we want to multiply our pain like that?
More classes in general is not a simplification. It’s when the new classes represent a separation of concerns that the simplification comes in. So we need to make sure our new classes do aim for the benefits described in section 2… and also not neglect to communicate our vision to those around us!
- Section 2 pictures the Single Responsibility Principle in action, while sections 1 and 3 picture Big Ball Of Mud.
- Thanks to Jon Fuller for helpful comments on the first draft of this.