Here’s all one should know about God Class in Java
By: Shalini Singh
Tags: Coding, Java, Programming, Software Engineering, Software Development

ILLUSTRATION OF GOD CLASS

Let’s say you are building a customer management application. Here’s the following snippet depicting the same.

God Class example screenshot by the author

This is a bit short example but if we rethink, a customer may have many other fields. Isn’t it a bit obvious that the Customer class has way too much information? What if a customer has several addresses in different cities, are they all going to be properties in this class?

While the application grows, this class also keeps on growing. Henceforth, after years of maintaining the application, we end up having a monstrous class having thousands of lines of code.

Now let's try to revisit our deductions on why this is considered to be a bad coding practice resulting in code smell. It looks very nice that you have access to all these pretty methods from one place and you claim that it’s less work to change a single file. This means whenever there’s a change in the class it is more likely to have bugs. Well, one bug is not big a problem, but the bugs getting compound is. Forget about solving, it becomes very hard to find two bugs which interact.

Even if the bug is detected and resolved. Can you imagine the pain of trying to test such a way too large class which has too many methods? I can assure even if we write unit test cases, it won’t be feasible to cover everything as this class is missing abstraction, which will result in exposing all the members of this class thus violating the principle of OOPS.

S ome more problems of having a “God Class”

All unwanted members of such class will be inherited to other classes during inheritance, violating the principle of code reusability.

The object will occupy more space in heap memory, so it will be an expensive operation in terms of memory management and garbage collection.

The phenomenon of tight coupling is noticed among such object class making the code difficult to maintain.

Unwanted threads will be running in the background thus at the time of parallel processing low priority threads might block high priority tasks to run.

Why and When does this happen?

Programmers face a conundrum of basic values. Every programmer has his own favorite formatting rules, but if he works in a team, then the team rules. A team of developers should agree upon a single formatting style, and then every member of that team should use that style. We want the software to have a consistent style. We don’t want it to appear to have been written by a bunch of disagreeing individuals.

Generally, this practice is noticed among programmers lacking experience in real-time programming and knowledge of the basics of programming language thus fails in developing an application with an architecture perspective.

We will often hear these common arguments like “But I need all this info in one easily-accessible place.” for the validity of God Object.

Strategic measure to prevent or resolve the God class or object:

Firstly, let’s focus on avoiding god Objects or class while developing.

Following The Boy Scout Rule

It’s not enough to write the code well. The code has to be kept clean over time. We’ve all seen code rot and degrade as time passes. So we must take an active role in preventing this degradation.

The Boy Scouts of America have a simple rule that we can apply to our profession.

Leave the campground cleaner than you found it.

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of duplication, clean up one composite if statement.

2. The Only Valid measurement of code quality is the count of WTF’s(Works That Frustrate)!!!!

Sources: - Clean Code By Robert C. Martin

3. Keep it Small!!!!!

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Even though we don’t have physical constraints given that we all use modern monitors, laptops, functions should hardly be 20 lines long and it should do only one thing.

FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.

Now, let’s focus on fixing God objects that already exist. The only solution for this is to refactor the object so as to split related functionality into smaller, manageable pieces. For example, let’s refactor the Customer.java from earlier:

Custome.java screenshot by the author

Address.java screenshot by the author

Now if we need to change the address data of any employee we would only need to change the Address class, not others.