God Class

Concept Definition

A God Class is a class that does too many unrelated jobs. It may store data, validate input, print UI, write files, calculate reports, and coordinate workflows all at once. The class becomes powerful, but also fragile.

Think of one student doing every role in a group project: coding, design, testing, slides, and presentation. It may work once, but it does not scale.

Why It Matters

God Classes violate the Single Responsibility Principle. When many reasons to change live in one class, every update risks breaking unrelated behavior. Testing also becomes harder because you cannot test one responsibility without dragging in the others.

In C++ OOP, a God Class often appears as a giant Manager class. Names like SystemManager, UserManager, or AppController deserve review when they contain too many responsibilities.

Syntax Block

class FocusedClass {
public:
    void oneClearJob(); // one responsibility
};

Explained Code

Example: Splitting Responsibilities

#include <string> // std::string

class PasswordValidator {
public:
    bool isValid(const std::string& password) const { return password.size() >= 8; } // validation
};

class UserRepository {
public:
    void save(const std::string& username) { (void)username; } // persistence boundary
};

class WelcomeEmailService {
public:
    void send(const std::string& username) { (void)username; } // notification boundary
};

Instead of one UserManager doing everything, each class owns one clear responsibility. The design is easier to test and change.

Key Points / Rules

• A class should have one clear reason to change.
• Large class size is a warning, not automatic proof.
• Look for unrelated method groups inside one class.
• Split by responsibility, not randomly by line count.
• Coordinator classes are acceptable when they coordinate instead of owning every detail.

Common Mistakes

1. Calling every large class a God Class. A class can be large because its one responsibility is large.
2. Splitting without naming responsibilities. Random splitting creates confusion, not design.
3. Moving code but keeping hidden coupling. If split classes still depend on each other's internals, the smell remains.
4. Putting all logic in main(). That is the procedural version of the same problem.

Quick Check

1. Why is UserManager a suspicious name?
2. Which SOLID principle is most related to God Class?

Viva Answer

A God Class has too many responsibilities. The fix is to split behavior into smaller classes with clear reasons to change.