God object: Difference between revisions
Removed entry based on personal opinion from See also section. |
m It's not THE basic idea of programming, the basic idea of programming is to create a set of instructions for the computer to follow. This is just a common idea. |
||
| Line 5: | Line 5: | ||
In [[object-oriented programming]], a '''god object''' is an [[Object (computer science)|object]] that ''knows too much'' or ''does too much''. The god object is an example of an [[anti-pattern]]. |
In [[object-oriented programming]], a '''god object''' is an [[Object (computer science)|object]] that ''knows too much'' or ''does too much''. The god object is an example of an [[anti-pattern]]. |
||
A common idea in programming is that a big problem is [[separation of concerns|separated]] into several smaller problems (a [[divide and conquer algorithm|divide and conquer strategy]]) and solutions are created for each of them. Once the small problems have been solved, the big problem as a whole has been solved. Therefore an object need only know everything about itself. Likewise, there is only one set of problems an object needs to solve: its ''own''. |
|||
A program that employs a god object does not follow this approach. Most of such a program's overall functionality is coded into a single "all-knowing" object, which maintains most of the information about the entire program and provides most of the [[subroutine|methods]] for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes god-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the god object for most of their information and interaction. Since the god object is tightly [[coupling (computer programming)|coupled]] to (referenced by) so much of the other code, maintenance becomes more difficult than it would be in a more evenly divided programming design. |
A program that employs a god object does not follow this approach. Most of such a program's overall functionality is coded into a single "all-knowing" object, which maintains most of the information about the entire program and provides most of the [[subroutine|methods]] for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes god-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the god object for most of their information and interaction. Since the god object is tightly [[coupling (computer programming)|coupled]] to (referenced by) so much of the other code, maintenance becomes more difficult than it would be in a more evenly divided programming design. |
||
Revision as of 15:14, 23 September 2015
 | This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. (March 2012) |
In object-oriented programming, a god object is an object that knows too much or does too much. The god object is an example of an anti-pattern.
A common idea in programming is that a big problem is separated into several smaller problems (a divide and conquer strategy) and solutions are created for each of them. Once the small problems have been solved, the big problem as a whole has been solved. Therefore an object need only know everything about itself. Likewise, there is only one set of problems an object needs to solve: its own.
A program that employs a god object does not follow this approach. Most of such a program's overall functionality is coded into a single "all-knowing" object, which maintains most of the information about the entire program and provides most of the methods for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes god-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the god object for most of their information and interaction. Since the god object is tightly coupled to (referenced by) so much of the other code, maintenance becomes more difficult than it would be in a more evenly divided programming design.
A god object is the object-oriented analogue of failing to use subroutines in procedural programming languages, or of using far too many global variables to store state information.
Whereas creating a god object is typically considered bad programming practice, this technique is occasionally used for tight programming environments (such as microcontrollers), where the slight performance increase and centralization of control are more important than maintainability and programming elegance.
See also
- Ravioli code, the opposite pattern
Further reading
- Riel, Arthur J. (1996). "Chapter 3: Topologies of Action-Oriented Vs. Object-Oriented Applications". Object-Oriented Design Heuristics. Boston, Massachusetts: Addison-Wesley. ISBN 0-201-63385-X.
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.
- Anti-Patterns and Worst Practices – Monster Objects.
 | This computer science article is a stub. You can help Wikipedia by expanding it. |