AntiPatterns: The God Class

We can all remember back to writing programs in our Intro to Programming course, where (if you were learning an OOP language like Java) you placed nearly everything into the main method just for the sake of learning. Projects continued to be approached like that for awhile, until you learned about inheritance and class hierarchies and why putting everything into main is actually not the best idea. It removes the basic principles of OOPs and essentially turns the project into a procedural program.

That is essentially what the God Class, AKA the Blob, does. Any related classes that are used are generally there to store data, and there is a big central class that is core to the functionality of the program. The God Class contains both operations and data relating to an extremely large amount of other classes, and acts as a controller for all of them. They generally seem to arise when time constraints and specification demands are placed on people who already have a shaky foundation in OOP principles. Either that, or often times when writing code developers will add small bits and pieces to existing software that they’re using, and some classes (especially controller-type classes) end up getting a disproportionate amount of these small changes over time.

In terms of drawbacks, there are a lot. It makes updating infrastructure far more complex than necessary, and it makes seamlessly fixing bugs in that system extremely difficult. Blobs are hard to test since there are just so many operations that work together within them, and when you create an object in memory there may be a significant portion of its’ functionality that you’re neglecting which soaks up running times.

So what can we do to refactor a God Class when we see it? First, find methods within the God Class that deal with one another and group them together. If developers have been slowly adding functionality to a controller that has resulted in a Blob-type class, then there should be a good amount of operations within it that could be grouped together. Then, either move those groups of operations into classes which they call upon in some way or create new, smaller classes which perform in the same way. Through doing this, you can extend the functionality of existing classes and reduce the complexity of your Blob. In the long term, reducing God Class complexity will assist in future testing, refactoring and will prevent annoying bugs from popping up that intrude on your beautiful OOP system design.

Leave a Reply

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

WordPress.com Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s