Because it’s easier to recognize evil if you have a mug shot, here’s one simple for all of you. The god object is a class that knows too much. It’s a severe violation of the Single Responsibility Principle and probably a lot of the other principle of SOLID depending of the implementation.
A basic principle in programming is to divide a problem in subroutines to make the problem easier to solve. It’s also know as “divide and conquer”. The object becomes so aware of everything or all the objects become so dependant of the god object that when there is a change or a bug to fix, it become a real nightmare to implement.
I tend to call those objects “Death Stars”. 
You can easily recognize of these object by the fear any developers have when getting near it.
So how to solve it? By refactoring of course! The goal is to separate in as much subroutine as possible. Once this is done, you move those subroutines to different classes. Of course, trying to follow the SOLID principles will definitely help.
Resolving a god object is of course really different depending on how omnipotent your god object is. But one thing for sure, you have to separate the “powers” (read: responsibility) and make sure that Single Responsibility Principle is applied.
But sometimes god objects are needed, they can be named Singleton, or Facase or even their combination. It all depends.
ReplyDeleteIn response to Paul's comment, god objects are not needed. A singleton or a facade isn't a god object.
ReplyDeleteA facade is an interface to other objects. The other objects are responsible for the work and therefore fit the SRP. The facade is just passing calls to the other objects... that's its responsibility. It has no idea how the work is getting done therefore it isn't a god object.
@Paul: A singleton is not necessarily a god object. Proper use of singletons (which is rare) has that singleton performing 1 responsibility. As such, you can't really call it a god object by default.
ReplyDelete