An object that knows too much or does too much.
TL;DR: Don't take too many responsibilities in a single class.
Problems
Solutions
Refactorings ⚙️
https://maximilianocontieri.com/refactoring-007-extract-class
https://maximilianocontieri.com/refactoring-002-extract-method
Examples
Context
God Objects form when you concentrate too many responsibilities in a single class.
These objects become central hubs that know everything and control everything in your system.
You create them gradually, with each added method making the class harder to maintain.
Libraries and utility classes from procedural programming encouraged this pattern in the 1960s.
Object-oriented design distributes responsibilities across many focused objects.
Sample Code
Wrong
class Soldier {
run() {}
fight() {}
driveGeneral() {}
clean() {}
fire() {}
bePromoted() {}
serialize() {}
display() {}
persistOnDatabase() {}
toXML() {}
jsonDecode() {}
// ...
}
Right
class Soldier {
run() {}
fight() {}
clean() {}
}
Detection
Linters can count methods and warn against a threshold.
Exceptions
Level
[X] Beginner
Why the Bijection Is Important ️
When you model your software, you need to maintain a clear bijection between your code and the MAPPER.
God Objects break this mapping by lumping multiple real-world concepts into a single artificial construct.
You will not find a single entity that manages users, processes payments, sends emails, and generates reports.
You have distinct roles and responsibilities.
When you create a God Object, you lose this clear correspondence, making your code harder to understand and maintain.
AI Generation
AI code generators frequently create God Objects when you ask them to "create a complete system" or "build a payment system.".
They tend to group related functionality into convenient single classes rather than distributing responsibilities properly.
You need to explicitly instruct them to separate concerns and create focused classes.
AI Detection
AI tools can detect God Objects when you provide clear instructions.
The assistants can count methods, analyze dependencies, and suggest splitting classes.
They struggle to determine the right boundaries without domain knowledge about your specific system.
Try Them!
Remember: AI Assistants make lots of mistakes
Suggested Prompt: Suggest how to split it into smaller, cohesive classes, each handling a single responsibility
Conclusion
Libraries were fine in the 1960s.
In Object-Oriented Programming, you need to distribute responsibilities among many objects.
Relations ❤️
https://maximilianocontieri.com/code-smell-34-too-many-attributes
https://maximilianocontieri.com/code-smell-202-god-constant-class
https://maximilianocontieri.com/code-smell-124-divergent-change
https://maximilianocontieri.com/code-smell-22-helpers
https://maximilianocontieri.com/code-smell-143-data-clumps
https://en.wikipedia.org/wiki/God_object
https://refactoring.guru/es/smells/large-class
https://coderlegion.com/6634/coupling-the-one-and-only-software-design-problem
Also Known as
Credits
Photo by Francisco Ghisletti on Unsplash
This article is part of the CodeSmell Series.
https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code