What are God Objects?

Question

I was reading the documentation of Woocommerce, and I came across the following line:

Avoid God Objects

God Objects are Objects that know or do Too Much. The point of Object-oriented Programming is to take a large problem and break it into smaller Parts. When functions of Too Much, it’s hard to follow their Logic, making bugs Harder to fix. Instead of having Massive functions, break them down into smaller Pieces.

In the excerpt it says: "God objects are objects that know a lot or do a lot". I did not understand the concept of it, even after reading in other sites.

What is an Object God and why we should avoid using them?

Answer 1

God Object is not far beyond what is said there. These objects are able to do many things, they do not follow the principle of single responsibility. Often the person creates them without realizing that this is happening, in exaggeration it is possible that the object is able to do everything of the application or of a good part of it, but it is more common to see cases that has two or more responsibilities, yet so to a small extent is also an exaggeration of calling an "object god".

The point is that some objects naturally have a unique responsibility and be a lot of things. An object Carro It is usually an object like this, it is a cohesive object that has many responsibilities, but they are encapsulated in other smaller objects and are not directly linked to the object of the car. Care must be taken to classify objects as gods in any situation.

In general the staff gives this name as antipattern for objects that know a lot about other objects, but it’s not always easy to define what is too much. The example of the car, of course he does not need to know the details of each part of the car, but he needs to know several points of contact with these objects. Of course, there techniques to help combat this, the composition is one of them, although some purists may find that.

The opposite of it is the "ravioli code" where there are a lot of small classes easy to understand by themselves, but when you go to use them together there is a huge confusion and the person gets lost.

People look at antipatterns to be avoided with a plague, but it is not quite so, often they serve a purpose and avoid one of them implies falling into another, has no way of running away from something bad, so you choose what is best for that case. Many examples I saw of solution solved one problem and caused another.

It is one of the many concepts that you only learn to use right with practice and if you have critical sense, then it serves as a guide to know that there is something like this, that it is a mistake to do something like this without a reason, but finding the exact point of application has nothing written that helps. Without much experience seeing the problems they give in maintenance it is difficult to follow right. And without mastery of the domain that is solving the problem it is easy to make mistakes.

It should be avoided because it usually keeps cohesion bad (I won’t go into detail here). And so can cause more side effects.

Note that classic OOP has always encouraged the use of these objects, there is a group that goes against this, and these people don’t even imagine that they are doing anything other than the name they are talking about. To avoid gods objects there is a tendency to break encapsulation.

See more.

Answer 2

In my view a God Object is a class/object that has many responsibilities, commonly associated with the phrase "Knows Too Much or does Too Much". Normally, God Object has such a strong coupling and dependency that any modification in its structure can affect an entire application. Hence being considered an anti-pattern and why it has to be avoided

Answer 3

The God Object (or Object God) is a portion of code (which can be a class or other item) that knows a lot or does a lot. In the worst cases, he knows and does a lot. It can also be known by the term God Class.

Usually it can be identified in the application when it begins to meet one or more of the following characteristics (some more subjective than others):

• Difficulty in understanding her responsibility; she has several. This violates a principle of the widely disseminated programming area known as SRP (Single Responsibility Principle).
• Difficulty testing for her
• Difficult maintenance; changes to it reflect on other portions of code, easily breaking its operation.
• Has many lines of code
• Hard to read code

Want to see what it looks like God Object? Let’s go to a example:

public static class EmployeeManager
{
    public static void HireEmployee(Employee employee) {...}
    public static void TerminateEmployee(int employeeID) {...}
    public static void EditEmployee(Employee employee) {...}
    public static void AddVacationTime(int employeeID, DateTime vacationDate) {...}
    public static void CancelVacationTime(int employeeID, DateTime vacationDate) {...}
    public static void AddAddress(int employeeID, Address address) {...}
    public static void RemoveAddress(int employeeID, int addressID) {...}
    public static void GiveBonus(int employeeID, decimal bonus) {...}
    public static void AssignEquipment(int employeeID, Equipment equipment) {...}
    public static void GiveRaise(int employeeID, decimal amount) {...}
    public static void DockPay(int employeeID, decimal amount) {...}
    public static void AddSchedule(int employeeID, Schedule schedule) {...}
    public static void AddPhoneNumber(int employeeID, string phoneNumber) {...}
}

This class clearly does many things that it could delegate to other classes.

The ways of refactoring this class are numerous, but we could start by having a class VacationManager, AddressManager, etc. We could also go deeper and create various objects representing the above business rule, creating objects Address, PhoneNumber, etc..

Anyway, we would already have a much better scenario than the one presented in the code above. This granularity would make it easier to identify code responsibilities, allow simpler maintenance and less risk of side effects, allow smaller and easier tests to implement, among other advantages.