At some point in the life of a programmer one will work on a legacy code base with an all-powerful, all-pervasive god object.
God objects provide a superficial simplicity that is all too attractive to both the novice and the stressed programmer. Placing all one’s faith in the god object feels like the right thing - it certainly feels easy, at first. The innocent programmer begins to fashion the god object, imbuing it with knowledge that no other object dares to possess. The god object becomes the answer to the programmer's prayers:
- Where is the control logic? The god object.
- Where shall I put this new logic? The god object.
- Where shall I find the state of the system? The god object.
- Where shall I seek out the answers to my questions? The god object.
The god object’s mysteries need to be fully understood before one can make an alteration or an addition to the functionality of their realm.
Once the god object is all powerful the novice who does not understand its mysteries risks falling victim to its wrath as calamitous consequences are unleashed. Hours, days and weeks of debugging follow the tragedy as valiant efforts are made to clear up the mess. The new novice has now learnt that only the truly enlightened dare to approach the god object.
Documentation
The mysteries of the god object are great, and those mysteries are recorded in the great documents.
The elders tell you that only through deliberate study of the documentation may you come to understand the mysteries of the god object.
From the outside the documentation may appear to be a single document, but it is actually a collection of documents from various authors.
Some documents tell the story of the god object, of how it enabled the creation of the system. Others tell of how one has interacted with the god object.
The documents were written long ago, but often after the events they described. A few dedicated individuals attempted to keep the documents up to date, revising them, but in the course of doing that they introduced inconsistencies and even some contradictory passages, leaving the documents not wholly truthful.
In the past there were many more documents, but one day the management convened a meeting of the senior programmers where they argued about which documents should be included and which excluded from the definitive set of documentation. Eventually they agreed, and non-canon documents were removed and archived.
The novice programmer may find that the documents have little bearing on the current situation one finds oneself in. They were written a long time ago and the authors of the documents are long departed. This leaves one with different interpretations of those documents; in intrepid programmer may even seek out the previous versions of the documents in order to better understand the intent of their authors.
Child God Object
A time may come to pass when a child of the god object is seen to hold similar power as the god object itself.
This may lead to some confusion. Is the child of the god object a separate god object? Are the god object and the child god object really one god object that is both separate and indivisible?
Beware of creating new god objects.
Priest Class
The need to understand the complete mysteries of the god object act as a hindrance to change. Rapid progress in the system is thwarted by the need to fully plan for and test the consequences of each change throughout the whole of the system.
Instead of communicating with the god object directly an intermediary shields one from full exposure to the mysteries. Separating the concerns of the god object from those of the new functionality, the priest class allows one to communicate through priest objects acting as intermediaries. The new isolated functionality can be unit tested with the effects of the god object mocked. The calls from the priest class to the god object can be analysed and meditated upon in isolation from the new functionality.
One comes to trust the priest class, but one is never quite sure whether it understands everything the god object does. But as the priest classes become more prevalent it is important that different priest objects serve different parishes with their own particular congregations of objects and functionality, otherwise the priest class risks becoming as mysterious and all-powerful as the god object itself.
The priest classes may start off using the same language as the new features, but as new features are added they use new languages while the priest classes continue to use their own older language.
Eventually the priest class can remove all direct interaction with the god object, and one day some Zarathustra will say that the god class is dead.
