sia.hackernoon.com

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 🛑

Facades

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

Code Smell 14 - God Objects