An object that knows too much or does too much.
TL;DR: Don't take too many responsibilities in a single class.
Problems 😔
- Low cohesion
- High coupling
- Single Responsibility Violation
Solutions 😃
- Split responsibilities.
- Follow the Single Responsibility Principle.
- Apply the Boy Scout Rule.
Refactorings ⚙️
https://maximilianocontieri.com/refactoring-007-extract-class
https://hackernoon.com/improving-the-code-one-line-at-a-time
Examples 📚
- Libraries
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 🛑
Tags 🏷️
- Coupling
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
Without Proper Instructions 📵
With Specific Instructions 👩🏫
Conclusion 🏁
Libraries were fine in the 1960s.
In Object-Oriented Programming, you need to distribute responsibilities among many objects.
Relations 👩❤️💋👨
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vii-8dk31x0
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xli
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxv
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-v-evj3zs9
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxix
More Information 📕
https://en.wikipedia.org/wiki/God_object
https://refactoring.guru/es/smells/large-class
https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h
Also Known as 🪪
- Large Class
Credits 🙏
Photo by Francisco Ghisletti on Unsplash
This article is part of the CodeSmell Series.
https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd