Large Class (The Blob)

A class that does too much.

“When a class has too many fields, duplicated code lurks.” – Fowler & Beck

Also known as The Blob or God Object.

Signs of Use (Symptoms)

  • Class has 50+ methods.
  • Class has 20+ fields.
  • Class name is vague (e.g., Manager, Helper, Utils).
  • Developers can’t agree on what this class is “for”.

Why it is bad (Consequences)

  • Change Impact: One small change can ripple through many unrelated features within the class.
  • Merge Conflicts: Everyone works in the same file.
  • Cannot understand: No one knows all the responsibilities.

Why it happens (Root Cause)

It’s the easiest place to add new code. “This class already does similar stuff, let’s add it here.”

When it might be okay (Exceptions)

  • Facade classes that intentionally aggregate many operations for a simpler API (but these should delegate, not implement).

Explanation

Problem

A class starts with one responsibility. Over years, it absorbs more and more.

The Flaw

Violates SRP. High coupling within the class itself. Low cohesion.

Real world analogy

A Swiss Army Knife with 50 tools. It does everything, but none of them well. Difficult to carry and use.

Refactoring Solution

  • Extract Class: Split into multiple cohesive classes.
  • Extract Subclass/Interface: If you see distinct “types” of behavior.

Pros and Cons (of the Antipattern)

Pros (Why people do it) Cons (The price you pay)
  • One place to find everything
    		•
  • Untestable
  • High coupling
    		•

    Comparison

    • Related Antipatterns: Long Method, God Component.
    • Related Principles: Violates SRP, High Cohesion.

    Code example

    Typescript

    Bad (The Antipattern)

    Good (The Fix)

    PHP

    Bad (The Antipattern)

    Good (The Fix)