God Object means an object that does too much or knows too much. To be more detailed this situation occurs when an object has knowledge of many different large parts of the system, it has an influence on them, the same way these large parts have to look to the God Object for some data or processing.
It often happens with User class, that often becomes a monster class.
While application grows this class also keeps growing and growing. Our User class has to deal with balance, profile, payments and so on. And after some months of maintaining our application, we end up a monstrous class with thousands and thousands of lines of code. Do you need registration? We add it to User class. Need to restore password? User class has a method for it. Do you want to process a payment? I think you know where to find this method.
But why is it wrong? It looks very nice that you have access to all these pretty methods from one place. But the flip side of this coin is that the user object causes things to happen in very different parts of the system. So, when we make some changes in this class there is a very big chance for bugs to appear and it will be very hard to find out the cause of them.
How to fix this issue? By refactoring, extracting parts of its methods into other classes. Fields and parameters that are used together might move into a new class.
Let’s have a closer look to our User class. We have some groups of methods that use only a small bunch of fields.
And statistics methods:
All of these methods groups can be extracted to their own classes: Balance, Profile and UserStatistics:
Now we have a set of small objects, each of them has its own responsibility.
In terms of object-orientated design, God Objects violate Single Responsibility Principle because they have too many responsibilities and reasons to be changed. They also violate the Law of Demeter, as they often have long methods chains to get access for required methods or properties.