God object
A god object ( English God object ) or God class ( English god class ) referred to in the object-oriented programming an object that "knows too much" or "too much is doing." The God object is an example of an anti-pattern .
The basic idea of structured programming is that large problems are broken down into a large number of smaller problems in order to find solutions for each of them. Solving the little problems means solving the big problem. Therefore every object only needs to know everything about itself and less about the others; likewise it only has to solve its own problem, not that of the other objects.
Codes based on God objects do not follow this paradigm. Instead, a large part of the functionality of a program is stored in a single object. Because this object contains so much data and methods, its meaning within the program becomes almost all-encompassing (god-like).
The individual objects do not communicate directly with each other, but are dependent on the one God object. Since the God object is so heavily referenced with the rest of the code, the maintenance of the program or the object becomes very difficult.
The use of a God object within object-oriented programming thus systematically corresponds to the poor use of subroutines or the excessive use of global variables in procedural programming .
While a God-Object is generally considered to be a characteristic of a weak program structure, it is common practice within limited environments such as the microcontroller , where fast performance is more important than maintenance. However, since microcontrollers are becoming more and more powerful, this argument is likely to become less and less important.
Big hairy object
A similar, often used synonymously slang term is that of the big hairy object . The main difference is that the Big hairy object, in contrast to the God object, does not take control of the program, but merely represents an overloaded interface.
literature
- Arthur J. Riel: Object-Oriented Design Heuristics . Addison-Wesley, Boston, MA 1996, ISBN 0-201-63385-X , 3: Topologies of Action-Oriented Vs. Object-Oriented Applications (3.2: Do not create god classes / objects in your system. Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem.).