Gottobjekt
Ein Gottobjekt (englisch God object) oder Gottklasse (englisch god class) bezeichnet in der objektorientierten Programmierung ein Objekt, das „zu viel weiß“ oder „zu viel tut“. Das Gottobjekt ist ein Beispiel für ein Anti-Pattern.
Die grundlegende Idee der strukturierten Programmierung besteht darin, dass große Probleme in eine Vielzahl kleinerer Probleme zerlegt werden, um für diese jeweils Lösungen zu finden. Das Lösen der kleinen Probleme bedeutet gleichsam die Lösung des großen Problems. Daher muss ein jedes Objekt nur über sich selbst wirklich alles wissen, weniger über die anderen; ebenso hat es nur sein eigenes Problem zu lösen, nicht die der anderen Objekte.
Codes, welche auf Gottobjekten basieren, folgen nicht diesem Paradigma. Stattdessen ist ein Großteil der Funktionalität eines Programms in einem einzigen Objekt hinterlegt. Da dieses Objekt so viele Daten und Methoden beinhaltet, wird seine Bedeutung innerhalb des Programms nahezu allumfassend (gottähnlich).
Die einzelnen Objekte kommunizieren also nicht direkt miteinander, sondern sind von dem einen Gottobjekt abhängig. Da das Gottobjekt derart stark mit dem übrigen Code referenziert ist, wird die Wartung des Programms, respektive des Objekts, sehr schwierig.
Die Verwendung eines Gottobjekts innerhalb der objektorientierten Programmierung entspricht also systematisch dem mangelhaften Gebrauch von Subroutinen oder der übermäßigen Verwendung globaler Variablen in der prozeduralen Programmierung.
Während ein Gottobjekt generell als Merkmal eines schwachen Programmaufbaus gilt, ist es gängige Praxis innerhalb begrenzter Umgebungen wie dem Mikrocontroller, bei dem eine schnelle Performance wichtiger ist als die Wartung. Da jedoch auch Mikrocontroller immer leistungsfähiger werden, dürfte diesem Argument immer weniger Bedeutung zukommen.
Big hairy object
Ein ähnlicher, oft synonym gebrauchter Slang-Begriff ist der des Big hairy object. Als wesentlicher Unterschied wird hingegen angeführt, dass das Big hairy object, im Gegensatz zum God object, nicht die Kontrolle über das Programm übernimmt, sondern lediglich eine überladene Schnittstelle darstellt.
Literatur
- 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.).