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.
I think it must be a relative object some think that there are others, some have the certainty that it was he who urged us, others doubt whether and this object or other, many deny the existence of the same
– ScrapBench