# God object

> Mediated Wiki article. Canonical URL: https://mediated.wiki/source/God_object
> Markdown URL: https://mediated.wiki/source/God_object.md
> Source: https://en.wikipedia.org/wiki/God_object
> Source revision: 1352397558
> License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/)

Large or very powerful object in programming

For an object worshiped as a god, see [Idol](/source/Idol_(disambiguation)).

This article includes a list of general references, but it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (March 2012) (Learn how and when to remove this message)

In [object-oriented programming](/source/Object-oriented_programming), a **god object** (sometimes also called an **omniscient** or **all-knowing object**) is an [object](/source/Object_(computer_science)) that references a large number of distinct types, has too many unrelated or uncategorized methods, or some combination of both.[1] The god object is an example of an [anti-pattern](/source/Anti-pattern) and a [code smell](/source/Code_smell).[2]

## Characteristics

This section may contain original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (March 2025) (Learn how and when to remove this message)

A common programming technique is to [separate](/source/Separation_of_concerns) a large problem into several smaller problems (a [divide and conquer strategy](/source/Divide_and_conquer_algorithm)) and create solutions for each of them. Once the smaller problems are solved, the big problem as a whole has been solved. Therefore a given object for a small problem only needs to know about itself. Likewise, there is only one set of problems an object needs to solve: its *own* problems. This also follows the [single-responsibility principle](/source/Single-responsibility_principle).

In contrast, 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 also provides most of the [methods](/source/Subroutine) 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-knowing and all-encompassing). Instead of program objects communicating among themselves directly, the other objects within the program rely on the single god object for most of their information and interaction. Since this object is [tightly coupled](/source/Coupling_(computer_programming)) to (referenced by) so much of the other code, maintenance becomes more difficult than it would be in a more evenly divided programming design. Changes made to the object for the benefit of one routine can have a ripple effect on other unrelated functions.

A god object is the object-oriented analogue of failing to use [subroutines](/source/Subroutine) in [procedural programming languages](/source/Procedural_programming), or of using far too many [global variables](/source/Global_variable) to store [state](/source/State_(computer_science)) information.

Whereas creating a god object is typically considered bad programming practice, this technique is occasionally used for tight programming environments (such as [microcontrollers](/source/Microcontroller)), where the [performance](/source/Computer_performance) increase and centralization of control are more important than maintainability and programming elegance.

## Example

The class GameManager in this [C++](/source/C%2B%2B) example can be seen as a "god object", doing everything from managing players, handling game logic, rendering, reading input and file I/O.

import std;

using std::string;
using std::vector;

class GameManager {
private:
    vector<string> players;
    int score = 0;
    bool running = false;
public:
    GameManager() = default;
    ~GameManager() = default;

    void addPlayer(const string& name) {
        players.push_back(name);
        std::println("Added player: {}", name);
    }

    void listPlayers() const {
        std::println("Players:");
        for (const string& p : players) {
            std::println(" - {}", p);
        }
    }

    void startGame() {
        running = true;
        score = 0;
        std::println("Game started!");
    }

    void updateGame() {
        if (running) {
            score += 10;
            std::println("Score updated: {}", score);
        }
    }

    void endGame() {
        running = false;
        std::println("Game over! Final score: {}", score);
    }

    void draw() {
        std::println("[Rendering Game Screen]");
    }

    void handleInput(const string& input) {
        if (input == "quit") {
            endGame();
        } else if (input == "score") {
            std::println("Current score: {}", score);
        } else {
            std::println("Unknown input");
        }
    }

    void saveGame() {
        std::println("Saving game state to disk...");
    }

    void loadGame() {
        std::println("Loading game state from disk...");
    }

    void run() {
        // ...
    }
};

Instead, this could be more appropriately divided among separated responsibilities:

import std;

using std::string;
using std::vector;

class PlayerManager {
private:
    vector<string> players;
public:
    PlayerManager() = default;
    ~PlayerManager() = default;

    void addPlayer(const string& name) {
        players.push_back(name);
        std::println("Added player: {}", name);
    }

    void listPlayers() const {
        std::println("Players:");
        for (const string& p : players) {
            std::println(" - {}", p);
        }
    }
};

class GameLogic {
private:
    int score = 0;
    bool running = false;
public:
    GameLogic() = default;
    ~GameLogic() = default;

    void startGame() {
        running = true;
        score = 0;
        std::println("Game started!");
    }

    void updateGame() {
        if (running) {
            score += 10;
            std::println("Score updated: {}", score);
        }
    }

    int getScore() const noexcept {
        return score;
    }

    void endGame() {
        running = false;
        std::println("Game over! Final score: {}", score);
    }
};

class Renderer {
public:
    Renderer() = default;
    ~Renderer() = default;

    void draw() {
        std::println("[Rendering Game Screen]");
    }
};

class InputHandler {
private:
    GameLogic& logic;
public:
    explicit InputHandler(GameLogic& logic):
        logic{logic} {}

    ~InputHandler() = default;

    void handleInput(const string& input) {
        if (input == "quit") {
            logic.endGame();
        } else if (input == "score") {
            std::println("Current score: {}", logic.getScore());
        } else {
            std::println("Unknown input");
        }
    }
};

class SaveSystem {
public:
    SaveSystem() = default;
    ~SaveSystem() = default;

    void saveGame() {
        std::println("Saving game state to disk...");
    }

    void loadGame() {
        std::println("Loading game state from disk...");
    }
};

class GameManager {
private:
    PlayerManager players;
    GameLogic logic;
    Renderer renderer;
    InputHandler input(logic);
    SaveSystem saves;
public:
    GameManager() = default;
    ~GameManager() = default;

    void run() {
        // ...
    }
};

## See also

- [Engineering portal](https://en.wikipedia.org/wiki/Portal:Engineering)

- [Ravioli code](/source/Spaghetti_code#Related) – the opposite pattern

## References

1. **[^](#cite_ref-1)** Riel, Arthur J. (1996). "Chapter 3: Topologies of Action-Oriented Vs. Object-Oriented Applications". *Object-Oriented Design Heuristics*. Boston, Massachusetts: Addison-Wesley. [ISBN](/source/ISBN_(identifier)) [0-201-63385-X](https://en.wikipedia.org/wiki/Special:BookSources/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.

1. **[^](#cite_ref-2)** Contieri, Maximiliano (2020-11-28). ["Code Smell 14 — God Objects"](https://blog.devgenius.io/code-smell-14-god-objects-b84b75b702). *Medium*. Retrieved 2023-03-06.

## External links

- [Anti-Patterns and Worst Practices – Monster Objects](http://www.lostechies.com/blogs/chrismissal/archive/2009/05/28/anti-patterns-and-worst-practices-monster-objects.aspx).

- [Code Smell 14 — God Objects](https://medium.com/dev-genius/code-smell-14-god-objects-b84b75b702)

---
Adapted from the Wikipedia article [God object](https://en.wikipedia.org/wiki/God_object) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/God_object?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.