This is a bit of a silly example, I'll admit, but it's a God object nonetheless. This Employee class has WAY too much information. What happens if some employee has seven kids? Are they all going to be properties in this class?

Clearly this class needs to be refactored, split into many classes (possibly including Spouse and Child classes). But what about a more... insidious example?

On the surface, this EmployeeManager class looks like it is organized properly. Every method has to do directly with employees; heck, every method takes an employee ID as the first parameter! It is what these methods most likely do, however, makes this tricky.

For example, take the GiveRaise and DockPay methods. In most countries, this process is, well, a process, taking multiple steps and needing multiple people's opinion. How much do you want to bet these two methods should be in their own class?

The same argument can be made for AddSchedule, or the Address functions. The fact is, this class is way too large, has too many methods, for it to function on its own. Can you imagine trying to test this?

When Does This Happen?

Like many software anti-patterns, the God object rears its ugly head most often when the programmer is lacking experience (or, alternately, getting terrible advice from his superiors). You will generally hear these common "arguments" for the validity of a God object:

"But I need all this info in one easily-accessible place." OR

"It's less work to change a single file."

Both of these arguments are fine in a vacuum, but both fall apart completely once the system in question needs to change in any manner. Aggregating lots of information under a single class means any time any of that information has to change, the class itself has to change, and that means with each change comes the possibility of introducing bugs. One bug is not a problem, but having more than one compounds the effort needed to track them down (e.g. how long does it take to solve one solitary bug versus two bugs which interact?).

So now we have two problems: first, how do we prevent God objects from occurring, and second, how do we fix them if they already exist? Luckily for us, they have the same solution.

Strategies to Solve

Let's start with fixing God objects that already exist. The solution is to smite refactor the object so as to split related functionality into smaller, manageable pieces.

Now, if we need to change the data tracked for an employee's spouse, we need only change the Spouse class, not any others. This makes it easier to refactor and test.

But what about preventing God objects from occurring in the first place? In this case, we also need to refactor, but not the code; rather, we need to refactor the design, which is far more difficult. Changing the design to support more "object-oriented" procedures saves you much time in the long run, because it allows your system to grow and adapt to change more readily.

And that's only the beginning. You could easily make an argument for AddSchedule and AddPhoneNumber to be in their own classes. But now, as before, if any of these need to change, only their corresponding classes will be affected, and not any of the others.

Summary

God Objects happen in poorly-designed systems, where an assumption happens that all necessary data needs to be kept tightly coupled. This assumption is almost always false. The solution is to refactor, either the code or the design, so as to split related functionalities into their own independent groupings, which allow them to change independently of one another and thus adapt to changes in the system.

In other words: smite the God Object.

Halllllllelujah!

Have you encountered God Objects in the wild? Are you too busy dodging lightning bolts to tell me about them? Find some shelter and let me know about your experiences in the comments! Or else head on back to the series index page to see some more anti-patterns.