Avoid god classes
From CSSEMediaWiki
(Difference between revisions)
m |
|||
Line 1: | Line 1: | ||
+ | :''Do not create god classes/objects in your system. Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem.'' --Riel's Heuristic 3.2, [[Arthur Riel 1996]] | ||
+ | |||
A god class is a class that either knows too much or does too much; a class that has to deal with too many responsibilities. The instantiated object of a god class is called a god object. | A god class is a class that either knows too much or does too much; a class that has to deal with too many responsibilities. The instantiated object of a god class is called a god object. | ||
Line 13: | Line 15: | ||
* [[One key abstraction]] | * [[One key abstraction]] | ||
* [[Antipatterns]] | * [[Antipatterns]] | ||
+ | |||
+ | [[Category:Riel's heuristics]] |
Revision as of 23:52, 20 July 2009
- Do not create god classes/objects in your system. Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem. --Riel's Heuristic 3.2, Arthur Riel 1996
A god class is a class that either knows too much or does too much; a class that has to deal with too many responsibilities. The instantiated object of a god class is called a god object.
Instead of having objects collaborate and distribute data among themselves, they rely to the god object as a "centralised data center". As a consequence of this, maintenance can become difficult. The god class usually has too many number of irrelevant functions or too many global variables.
However, there is an instance in which a god class is particularly useful, where performance is needed over maintainability (eg. micro-controllers or hardware programming).
God class/god object is a known software design antipattern.