How more can be simpler

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.

1. The Existing Routine

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.

2. How More Can Be Simpler

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.

3. Why It May Not Sound Simpler

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?

4. Conclusion

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!


  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s