God objects are a common anti-pattern in object-oriented programming, where a single class or module has too many responsibilities, dependencies, and methods. They violate the principles of cohesion, coupling, and encapsulation, and make the code hard to maintain, test, and reuse. In this article, you will learn how to identify and fix god objects using some design patterns and refactoring techniques.
A god object is a class or module that knows too much or does too much. It may have many fields, methods, parameters, and conditional logic that deal with different aspects of the system. It may also access or manipulate the data and behavior of other classes or modules directly, without using interfaces or abstraction. A god object is a sign of poor design, as it breaks the single responsibility principle, which states that each class or module should have one and only one reason to change.
One way to identify a god object is to look at its size and complexity. If a class or module has hundreds or thousands of lines of code, dozens of methods, fields, and parameters, and many nested if-else or switch statements, it is likely a god object. Another way to identify a god object is to look at its dependencies and cohesion. If a class or module depends on many other classes or modules, or has low cohesion, meaning that its methods and fields are not related to each other, it is likely a god object.
There can be various instances of god objects in your code. For ex. - A general tendency of the developers is to throw all general purpose functions in a single class and name the class as CommonLib or CommonFuntions. - Wrap all the dependencies of an object in the same class. For example, The User class might be handling the details of the User, the sign up and login functions, generating a performance report and also the functionality to send the emails and notifications.
The main goal of fixing a god object is to split it into smaller and more cohesive classes or modules, each with a clear and single responsibility. There are several design patterns and refactoring techniques that can help you achieve this goal, such as Extract Class, Extract Method, and Replace Conditional with Polymorphism. For example, you can use Extract Class to create a new class or module that encapsulates some of the fields and methods of the god object, or Extract Method to create a new method that contains some of the logic of a long or complex method of the god object. Additionally, you can use Replace Conditional with Polymorphism to use inheritance and polymorphism to replace long or complex conditional logic with different subclasses or implementations of an abstract class or interface.
God objects are notorious for accumulating multiple responsibilities, thus violating the Single Responsibility Principle (SRP). SRP is one of the 5 SOLID principles of object-oriented design. It states that a class should have only one reason to change. In simpler terms, a class should be responsible for just one task. Adhering to SRP has several benefits like increased cohesion, simpler maintenance, improved reusability and easier testing.
Fixing a god object can bring many benefits to your code quality and performance, such as improved readability, maintainability, testability, reusability, performance, and scalability. By splitting the object into smaller and more cohesive classes or modules, you can make your code easier to read, understand, modify, and test. Additionally, you can avoid duplication and inconsistency, follow the principles of don't repeat yourself (DRY) and open/closed (OCP), reduce memory and CPU consumption, and improve scalability by distributing and parallelizing the work of different classes or modules.
You'll make developers lives easier, not just for you, but for your teammates and whole application by fixing "god" objects. People who made god objects maybe had no other choice (deadlines, business needs), might have thought that no one will review their code, because sometimes you don't want to deal with such a person (such people think they are "gods". They have pre-defined rights to do whatever they want, always approved by management), maybe some of them want to secure long-term job as only they can read/understand/maintain the "god" class and they can't be fired. Therefore, from business perspective, it would be better to prevent the existence of a "god" class at earlier stages of development.
Illustrating how to fix a god object, let's look at a simplified example of a god object in Python. This class, called Calculator, has an excessive amount of fields, methods, parameters, and conditional logic dealing with various types of calculations such as arithmetic, trigonometry, and statistics. It violates the single responsibility principle and has too many reasons to change; for instance, if we want to add a new type of calculation, such as logarithm, we must modify the class by adding a new method and a new case in the calculate method. This complexity makes the class hard to maintain, test, and reuse.
To address this issue, we can apply design patterns and refactoring techniques such as Extract Class, Extract Method, and Replace Conditional With Polymorphism. For example, we can create separate classes or modules for each type of calculation and move the related fields and methods to them; create an abstract class or interface that defines a common method that each subclass or implementation must override; create a new method that contains the logic of appending the result to the history list and formatting the output; replace the long conditional logic in the calculate method with different subclasses or implementations of the Calculation class or interface; use a dictionary or factory method to map each operation to the corresponding subclass or implementation; and call the execute method on them.
The refactored code is much better than the original god object as it follows design principles and patterns while improving code quality and performance. It also avoids duplication and inconsistency while following DRY principle and makes code more readable and maintainable while following OCP principle.