GodClass [anti-pattern] v1.0.0

A class that accumulates responsibilities across multiple domains — handling data fetching, business logic, formatting, caching, and state management all in one place. The God Class is the most common violation of the Single Responsibility Principle.

Label

God Class — a class that does everything

Why Bad

A God Class is untestable (you cannot instantiate it without standing up its full dependency graph), unmaintainable (every new feature goes in because there is no other obvious place), and fragile (a change to caching logic can break formatting logic because they share private state). Code review becomes impossible because the diff touches everything.

Instead Do

    Split by responsibility. Example — a 1,200-line UserService becomes:

    UserRepository      — DB queries only (fetchById, save, delete)
    UserValidator       — validation rules (isEmailValid, isAgeAllowed)
    UserEmailService    — email sending (sendWelcome, sendReset)
    UserSessionService  — session creation and expiry
    UserController      — HTTP layer, composes the above

    Each class: < 200 lines. Each class testable in isolation.
    Dependencies injected — no `new X()` inside methods.
  

GodClass [anti-pattern] v1.0.0

A class that accumulates responsibilities across multiple domains — handling data fetching, business logic, formatting, caching, and state management all in one place. The God Class is the most common violation of the Single Responsibility Principle.

Label

God Class — a class that does everything

Why Bad

A God Class is untestable (you cannot instantiate it without standing up its full dependency graph), unmaintainable (every new feature goes in because there is no other obvious place), and fragile (a change to caching logic can break formatting logic because they share private state). Code review becomes impossible because the diff touches everything.

Instead Do

    Split by responsibility. Example — a 1,200-line UserService becomes:

    UserRepository      — DB queries only (fetchById, save, delete)
    UserValidator       — validation rules (isEmailValid, isAgeAllowed)
    UserEmailService    — email sending (sendWelcome, sendReset)
    UserSessionService  — session creation and expiry
    UserController      — HTTP layer, composes the above

    Each class: < 200 lines. Each class testable in isolation.
    Dependencies injected — no `new X()` inside methods.
  

Relations

related: [@team/principle-readability-over-cleverness, @team/anti-pattern-comment-explaining-bad-code, @team/rule-test-each-public-fn] see-also: [@team/anti-pattern-comment-explaining-bad-code]

Label

God Class — a class that does everything

Why Bad

A God Class is untestable (you cannot instantiate it without standing up its full dependency graph), unmaintainable (every new feature goes in because there is no other obvious place), and fragile (a change to caching logic can break formatting logic because they share private state). Code review becomes impossible because the diff touches everything.

Instead Do

    Split by responsibility. Example — a 1,200-line UserService becomes:

    UserRepository      — DB queries only (fetchById, save, delete)
    UserValidator       — validation rules (isEmailValid, isAgeAllowed)
    UserEmailService    — email sending (sendWelcome, sendReset)
    UserSessionService  — session creation and expiry
    UserController      — HTTP layer, composes the above

    Each class: < 200 lines. Each class testable in isolation.
    Dependencies injected — no `new X()` inside methods.
  

See Also

• @team/anti-pattern-comment-explaining-bad-code