Introduction

The God object is a part of the code smell group and it is a kind of object that knows too much or does too much. That means a huge class in terms of number of lines of code. It is very famous in bad programming because it creates tight coupling and increases the challenges in the code maintainability. If a class contains too many functions or properties, then it increases the lines of codes in that class and this class will suffer from God Object, a bad programming practice. It is a kind of an Anti-Pattern because it opposes a common design principle.

Two famous SOLID principles are "Single Responsibility" and "Interface Segregation." The main objective of these two principles is to separate the large solution into small pieces of logical code blocks with interfaces and classes. But, the God Object doesn't care about these principles. So, it enters into the category of anti-design pattern.

Below is an example of a class that is a God Object.
  1. using System;
  2. namespace DelegateExample {
  3. public class EmployeeUtils {
  4. public void FetchEmployeeDetails(string employeeId) {}
  5. public void SaveEmployeeDetails(EmployeeModel employeeDetails) {}
  6. public void ValidateEmployeeDetails(EmployeeModel employeeDetails) {}
  7. public void ExportEmpDetailsToCSV(EmployeeModel employeDetails) {}
  8. public void ImportEmpDetailsForDb(EmployeeModel employeeDetails) {}
  9. private class EmployeeModel {
  10. public string EmployeeId {
  11. get;
  12. set;
  13. }
  14. public string EmployeeName {
  15. get;
  16. set;
  17. }
  18. public string EmpplyeeAddress {
  19. get;
  20. set;
  21. }
  22. public string EmployeeDesignation {
  23. get;
  24. set;
  25. }
  26. public double EmployeeSalary {
  27. get;
  28. set;
  29. }
  30. }
  31. }
  32. }

The EmployeeUtils class above contains three major design smells.

Solution of the above God Object class

It should follow the SOLID Principle. Interface segregation will be a very good solution for this class.

Create separate Model class for the "EmployeeDetails" like below.

  1. public class EmployeeModel
  2. {
  3. public string EmployeeId { get; set; }
  4. public string EmployeeName { get; set; }
  5. public string EmpplyeeAddress { get; set; }
  6. public string EmployeeDesignation { get; set; }
  7. public double EmployeeSalary { get; set; }
  8. }

Divide functionalities into different classes and interfaces, like below.

Import Export

  1. public interface IImportExport
  2. {
  3. void ExportEmpDetailsToCSV(EmployeeModel employeDetails) { }
  4. void ImportEmpDetailsForDb(EmployeeModel employeeDetails) { }
  5. }
  7. public class ImportExport IImportExport
  8. {
  10. }

Database operation for employee

  1. public interface IEmployeeDbOperations
  2. {
  3. void FetchEmployeeDetails(string employeeId) { }
  4. void SaveEmployeeDetails(EmployeeModel employeeDetails) { }
  5. }
  7. public class EmployeeDbOperations IEmployeeDbOperations
  8. {
  9. }

Validation operation for employee

  1. public interface IEmployeeValidation
  2. {
  3. void ValidateEmployeeDetails(EmployeeModel employeeDetails) { }
  4. }
  6. public class EmployeeValidation IEmployeeValidation
  7. {
  8. }
Class Diagram

Symptoms of God Object

Below are the common symptoms of God Object

Problems with God Object

The below problems are faced when we encounter God Object.

How to refactor God Object class?

God object can be refactored and fixed. Below are the ways.

  • Try to use "Interface Segregation" principle and delegate calls to the new extracted classes.
  • Write unit test for each method.
  • Use separate model classes for fields or properties.
  • Don't make methods large. Divide into different logical methods.
  • If module is large, then try to use any design pattern.
Conclusion

God Object is a kind of anti-pattern. It opposes the design pattern. It spoils the code and makes the enhancement, unit test, and re-usability part very difficult. It is very expensive to load into memory.