DEV Community

Dibyojyoti Sanyal
Dibyojyoti Sanyal

Posted on • Originally published at cloudnativemaster.com

How to avoid God Class in OO Programming ?

When we learn programming we tend to put all the code in the same function or even in the same file. Especially in the functional programming paradigm, for example in C, where the program logic is driven by sequence of method calls and execution logic rather than communication between objects. Object oriented programming supports communication driven program execution among representations of real world objects. In functional programming as the starting point is the main method we tend to write the whole program in the same method. Sometimes we factor out the logic in separate methods which are called sequentially from the main method. At best we create separate files that contain few methods, this file can be reused. In Object oriented programming everything revolves around a few objects where one of the classes contains the main method and acts as the entry point. Object Oriented design principles suggest that there should not be one single God class. Today we will discuss what that exactly means and how to avoid creating God class.

What is a God Class or a God Object?

A God class is a class that tends to have every solution possible logic. Rather than provisioning a solution to a specific problem a God Glass tends to have different kinds of code logic that solve different problems. When we can call different methods on the same object to perform different tasks we can say the object is doing too much and it's a God object. Wikipedia has a good explanation on the God object.

Why do we need to avoid God Class and God Object ?

There are many problems that are associated with God classes and God objects. Few of them I have mentioned here:

  • The size of code with a class increases and makes it unnecessarily complex.

  • God Class and God objects creates tight coupling between unrelated code which becomes difficult to enhance and maintain in future.

  • The single responsibility principle in object oriented design principles says one class should only do one thing. This principle is not followed in God classes and God objects.

  • As these classes and objects do many tasks they lack modularization concept which hinders code reusability.

  • Different independent code logics are intertwined in God classes and God objects. For this reason, testing of each functionality separately becomes difficult.

How to detect God Class ?

I have listed a few tips that will help you detect God Class and God Object.

  • Like the main method in C which is the entry point and central component that manages the whole working and dataflow, when you find similar classes or methods you can smell God Class.

  • Generally Gog Classes have a large number of code lines.

  • A class that performs several tasks to solve different not related or less related problems are candidates for God Class. Generally these classes offer a lot of functionality which are not related.

  • When a class has many unrelated properties and exposes methods to manipulate or fetch those properties, this class becomes a God Class.

How to refactor a God class ?

A systematic approach will let you identify, plan and get rid of the God classes and God objects.

  • The first step is to identify the God classes and objects in each package and module.
  • Next, we need to identify the clients of the God classes and objects who use these classes and objects. It will help us to assess the impact of the change we are going to perform.
  • Then we need to come up with a new low level design to remove God classes and objects. In the design we need to take care of these below points.
    • For the static methods a separate utility class needs to be created because an object is not needed to invoke the static methods.
    • Similarly the static and final variables can be separated out.
    • Group common methods and properties following single responsibility principle. Create separate classes for each group.
    • Use inheritance, association and aggregation to establish a clear relationship among the classes.
    • Use high cohesion and low coupling principles.
  • Factor out the less frequently used part first and then work on refactoring other parts.
  • Create unit tests to test the new code thoroughly.

How to avoid creating a God class ?

There should not be one single class that does all. Instead there should be a bunch of classes which are needed to perform some tasks in a certain sequence, and will be used at different points of time in the sequence. In certain scenarios it makes sense that, once the work of a class is completed it can be garbage destroyed or collected. To avoid one class performing more than one task, before creating a class create an interface and define the methods the interface will contain. Carefully, look at the interface methods to judge whether the methods solve only one task and the contract as a whole provides one functionality. Once you are sure, implement the interface in a class.

You can refer to my blog post for example of God classes and solution of how we can avoid creating God classes.

Top comments (1)

Collapse
 
efpage profile image
Eckehard • Edited

There are some guidlines to create classes or class hierarchies:

  • put only things together that belong to the same task. If your program needs to access a database and does some graphics, you probably should not put things together in one class
  • Can you avoid external dependencies? A class hierarchy is a relative closed context. If your class is well designed, it will mainly rely on internal data.
  • Do you have much redundancy in your code? If you find similar code blocks in different routines, this is a sign that you should reorganize your code and possibly create some abstract parent classes that containt this redundant code. An abstract class will usually never called from outside the class, but provides some useful service for other members of the "family".

It is often not easy to set up useful class hierarchies and may need a lot of refractoring and reorganization to get anything on the right place. But it will make your code much better maintainable.