There are situations where it makes sense to code like a banshee. Perhaps you have a deadline in six hours, or you are prototyping some code that you’re going to throw away before starting on the final implementation. In these types of situations, you generally will hurt your progress by over engineering the task before you. Generally speaking, though, these are the exceptions not the norm. As you work on larger and larger projects that interface with more and more people, you will find that adapting certain fundamental approaches to software engineering will reinforce your project’s viability over the long term. In really massive projects, you’ll often find yourself going back to code you wrote over a year ago. With the right development habits in place, doing that should be as easy as if you’d written the code last week. Like consistent coding conventions, using the single responsibility principle is another step along the path to improving your development habit and writing maintainable code.

The God Object Antipattern

At the end of last weeks’ article on Design Patterns, I introduced the concept of anti-patterns and other design choices that hurt code maintainability and discourages code reuse.

One of the easiest antipatterns to fall in to, particularly in a top down development environment, is that of the God Object. The God Object is simply “an object that knows too much or does too much” (source: wikipedia). In a game development environment, the class that is most likely to turn into a god object is the all powerful “Game” class that is trying to mesh entity management, input processing, network routing, collision detection, scripting, etc. etc. etc. Because our god object suddenly does so much, it becomes all too easy to make it a singleton and thus combine two antipatterns to create a game engine that we can never reuse again after this project.

Why Are God Objects Bad?

The God Object is bad for two reasons:

1. It knows too much. This violates one of the requirements of writing maintainable code, and that is loose coupling. What it comes down to is that if everything is touching and/or using your god object, when it changes, lots of things will break. Or, you’ll decide not to change it because it’ll be too much work to fix. Bad either way. Loose coupling is a topic for itself, though, so we’ll pick this up some other day.

2. It does too much. One of the other tenets of writing maintainable code, is producing code with high cohesion. One remarkably simple technique that helps promote high cohesion is the single responsibility principle. Basically, the single responsibility principle (SRP) says that a class should only ever do one thing, because that means it only ever has one reason to change.

Don’t Make Change Bad

Changing a class means that anything it uses or is used by can potentially break. If a class does two things, and you change one, anything that relied on either piece now represents an additional possibility for failure. Code structure that introduces two times the possibility for failure as a result of a single change is inherently less robust than code that doesn’t. This is the essence of the single responsibility principle. Ensure that each class has only a single reason to change.

Refactoring Existing Code

Applying the single responsibility principle to pre-existing code starts off with the question, “What is the class supposed to do?” If the answer uses the word “and” or “or”, then chances are it could be improved by separating it into two classes that together accomplish the different tasks separately.

The Benefits of Single Responsibility

1. It eases development of new code. Implementing new classes with the single responsibility principle in hand is actually easier, if applied diligently, than designing without it. Classes that have a single responsibility are surprisingly easy to test because they tend to be highly modular. You can test each component in a sandbox as you’re building it out, and because it’s only ever doing one thing, your old test cases won’t break down as you introduce new functionality to your system.

2. Classes are easier to inspect and read. Generally speaking, the more code that surrounds a particular task, the more difficult it is to understand the code (whether you’re coming back to it after six months or if someone else wrote it). With the SRP principle, classes will max out in a few hundred lines. Gone are the days where you’re exhaustively searching a 3,000 line class file trying to isolate a bug. Your brain can keep track of 150 pieces of information far easier than 3,000. Suddenly your code becomes both either to understand and easier to maintain.

3. Code becomes reusable almost for free. When you’re working on a project and you discover you need a particular solution, you immediately realize you’ve already solved this exact same problem, and only that problem, in another class you implemented on a previous project. You can drop that file into your new project with very little integration effort because it doesn’t have 15 other unrelated dependencies that need to be removed first. When sharing code between projects becomes as effortless as a file copy paste, you start to get a lot more done in less time.

Integration Through Application

Old habits die hard. I still give in to the temptation to add just one other piece of functionality to a class, and every time I do, I ultimately regret it. That one little addition turns into three, then six and then suddenly I have a huge fugly class that I know I will never be able to understand or reuse again after this project. The only way to stop this endless cycle is to equip yourself with the tools to avoid it, and the easiest first step is taking the single responsibility principle approach to class design.

Applying this principle is the best way to work towards getting out of the God Object antipattern and one of the easier ways to ease development and encourage reusable maintainable code.