Godless development: how to find and avoid God Objects

Have you ever written or encountered a class that does too many things? A class that takes care of almost everything and you can make an object from it and use it in various aspects of application development. Yes, you found a God Object:

In object-oriented programming, a God object is an object that knows too much or does too much. The God object is an example of an anti-pattern.


Usually, you can see these ani-pattern codes from the work of less-experienced programmers who believe that one big class can help them complete their tasks more quickly and less work is needed to change a single class compared to be forced to change a couple of them.

Below is the example of a God Object:

public class UserInfo {

public Long userId() {}
public String fullName() {/*getter & setter*/}
public LocalDate birthday() {/*getter & setter*/}
public String email() {/*getter & setter*/}
public String userName() {/*getter & setter*/}
public String password() {/*getter & setter*/}
public String maritalStatus() {/*getter & setter*/}
public String gender() {/*getter & setter*/}
// and so on ...

// some validators to validate user info before saving to DB
private boolean validateUsername(String userName) {}
private boolean validateEmail(String email) {}
private boolean validatePassword(String password) {}
private boolean isRegisteredBefore(String userName) {}
private LocalDate convertDate(String birthday) {}

public void saveUserInfo() {}
public List<Map<String, String>> fetchUserInfo(){}
public JSONObject exportUserInfoToJSON() {}
public void exportUserInfoToCSV() {}
public void importUserDataFromCSV() {}
public void deActivateUser() {}


As you can see from the example above, the UserInfo class is responsible for various pieces of the program’s functionality such as inserting and retrieving data to database, exporting and bulk importing user information, validation, and so on. In other words, the programmer has many reasons to change the codes of this class which is a vivid violation of the Single Responsibility Principle. But, let’s take a look at what problems these kinds of codes can make:

God Object drawbacks:

  • Difficult to write unit tests
  • Increases complexity and makes the development difficult and costly
  • Increases tight coupling
  • Takes more resources and is very expensive in memory usuage.
  • Doesn’t follow the SOLID principle.

Therefore, how to avoid god objects to occur in the first place?

The first you can do is to stop writing very large methods. Then, try to write unit tests for each method. And, last but not least, start learning about design patterns and object-oriented paradigm because following OOP principles save you a considerable amount of development time in the long run. It will increase the readability of codes and will make the final application more reliable and adapted to future changes.