Here’s all one should know about God Class in Java
Most of the java developers seek it but fail to attend
Java is the second most popular and widely used programming language of the 21st century for the creation of web applications and platforms. It is a write-once run anywhere (WORA) programming language developed by James Gosling at Sun Microsystems.
OOPS… Yeah, that’s what is Java, an Object-Oriented Programming language. Everything in java is Objects, if you know how to play with objects it can become one of your favorite games.
Are you all setup to know more about God class in JAVA?
We are all aware of the design pattern, but do you know that we also have an anti-pattern in software development, and god class is one of them. It does not follow any design pattern principle and code cannot be reused for such classes.
Before we jump directly into the practical application of this concept, let us familiarize ourselves with a few terminologies
GOD CLASS :- One class to rule them all and in the darkness bind them. A “God Class” is an object that controls way too many other objects in the system and has grown beyond all logic to become The Class That Does everything. It is a class that centralizes the intelligence in a system given that it is large and complex and uses data from other classes.
GOD OBJECT :- It occurs in software development when a single class knows too much and does too much. To be more precise, this situation arises when an objects becomes monolithic holding information of many other larger parts of the system. While this being useful in some circumstances , it qualifies itself to be a part of code smell group.
ILLUSTRATION OF GOD CLASS
Let’s say you are building a customer management application. Here’s the following snippet depicting the same.
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.
Some 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)!!!!
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:
Now if we need to change the address data of any employee we would only need to change the Address class, not others.
Final Thoughts
God Objects happen in poorly-designed systems, where an assumption happens that all necessary data needs to be kept tightly coupled.
Have you encountered God Objects in your application? Please share your experiences.
Thanks for reading.
If you found this article helpful or thought-provoking, leave a comment, and let’s connect over LinkedIn!
