What is the "god object" anti-pattern in software design, and why is it considered harmful?
answer
- one class, all responsibilities
- low cohesion + high coupling
- top of the git-churn list
- tests need the whole world
- extract by field clusters, delegate
basics
~20 sA god object is one class that knows and does almost everything: data, rules, coordination, I/O. Because everything depends on it and every feature edits it, it is hard to understand, hard to test, and a constant source of conflicts and bugs.
solid answer
~50 sA god object (a.k.a. god class or "the blob") is a single unit that has accumulated responsibilities from many unrelated concerns. Its symptoms are low cohesion (methods operate on disjoint subsets of its fields, so there is no single reason for it to exist) and high coupling (most of the system either calls into it or is called from it). The costs are concrete: you cannot understand a change locally, every feature touches the same file so teams collide in merges, unit tests need huge setup because instantiating it drags in every dependency, and a bug in one concern can corrupt state used by an unrelated concern. It is the practical violation of the Single Responsibility Principle. The cure is incremental: add characterization tests, find clusters of fields used together, extract those clusters into focused classes, then delegate — never a big-bang rewrite.
go deeper
Define it (one class doing too much), name one concrete pain (hard to test / everyone edits it), and mention the Single Responsibility Principle.
Add the cohesion/coupling vocabulary, list recognition signals (field clusters, churn, fan-out), and describe extract-class refactoring with delegation.
Discuss why it becomes a team coordination bottleneck, why big-bang rewrites fail, characterization tests, interface segregation for callers, and lint/architecture guardrails against regrowth.
Frame it as an organizational and risk problem: change amplification, ownership, strangler migration sequencing, measuring progress (churn, coupling metrics, incident rate), and deciding when tolerating it is the correct economic call.
## The name **God object** (also *god class*, *blob*, *kitchen-sink class*) is a design anti-pattern: a recurring "solution" that looks convenient in the moment but reliably makes the system worse. The class is called a *god* object because it knows about, and controls, nearly everything in the program. ## Two definitions you need first - **Cohesion** — how strongly the parts of one unit belong together. High cohesion: every method uses the same handful of fields toward one purpose. Low cohesion: method group A touches fields `a1,a2`, group B touches `b1,b2`, and the two groups never meet — that class is really two classes stapled together. - **Coupling** — how much other code depends on this unit (incoming/afferent) and how much it depends on others (outgoing/efferent). A god object typically has both very high. A god object is therefore the extreme point of **low cohesion + high coupling**, which is the opposite of the classic design goal ("high cohesion, low coupling"). It is the most visible violation of the **Single Responsibility Principle (SRP)** — the idea that a unit should have one reason to change. ## How to recognize one (signals, not proof) 1. **Size**: hundreds or thousands of lines; dozens of fields; dozens of public methods. 2. **Disjoint field usage**: you can partition its methods into groups that touch non-overlapping fields. (Formalized by cohesion metrics such as *LCOM*, "lack of cohesion of methods".) 3. **Import/dependency fan-out**: it references the database, the HTTP layer, the domain rules, formatting, caching, logging config… 4. **Git churn**: it is the top file in "most frequently changed" and the top source of merge conflicts. Every unrelated feature branch edits it. 5. **Naming smell**: `SystemManager`, `AppHelper`, `Utils`, `DataProcessor` — vague nouns that cannot be violated by any addition, so everything gets added. 6. **Test setup pain**: constructing it in a unit test requires mocking eight collaborators you do not care about. ## Why it actually hurts - **No local reasoning.** To change one behavior you must convince yourself you did not break the other twelve behaviors sharing its mutable state. - **Change amplification and collisions.** Because it is the intersection point of all features, unrelated teams serialize on it (a coordination bottleneck, not just a code smell). - **Untestability.** Its dependencies are transitive: instantiate it and you drag in the whole system. Tests become slow integration tests or don't get written. - **Hidden invariants.** Shared mutable fields create implicit ordering rules ("you must call `init()` before `render()`") that no type or signature expresses. - **Blocked reuse.** You cannot reuse the 5% you want without taking the other 95%. - **Concurrency hazard.** One big mutable state blob is where data races congregate. ## When a big class is *not* a god object - A **façade** or **API surface** that only *delegates* to focused collaborators can legitimately be wide but is thin and stateless — width alone is not the sin; hoarding *state and unrelated logic* is. - **Generated code**, tables of constants, and exhaustive mapping/serialization code can be long yet perfectly cohesive. - In a 200-line script, one class doing everything is fine. Anti-patterns are context-dependent; the cost only appears with scale, team size, and lifetime. ## How to unwind one (incrementally) 1. **Pin behavior first** with *characterization tests* — tests that assert what the code currently does, so a refactor that changes behavior fails loudly. 2. **Find the seams**: cluster methods by which fields they touch; each cluster is a candidate class. 3. **Extract class / move method** one cluster at a time; leave the original methods as one-line delegations so callers keep compiling. 4. **Narrow the interfaces**: give each caller only the operations it needs (Interface Segregation), which shrinks incoming coupling. 5. **Invert dependencies**: pass collaborators in (constructor injection) rather than having the class construct or look them up. 6. **Strangle**: route new features to the new focused classes; let the god object shrink until it can be deleted. 7. **Guardrails**: a size/complexity lint rule or an architecture test so it does not regrow. The key discipline is that the refactor is a sequence of small, individually shippable, behavior-preserving steps. Big-bang rewrites of god objects fail because the god object is precisely the place where undocumented business rules were hiding.
- Is a large class always a god object?No. Size is a signal, not the definition. A long but cohesive class (a mapping table, generated code, or a thin façade that only delegates) is fine. The defining traits are low cohesion — methods operating on unrelated field subsets — plus high coupling to the rest of the system.
- What is the first thing you do before splitting one?Write characterization tests that lock in current observable behavior, because a god object usually hides undocumented business rules. Only then extract classes in small, behavior-preserving steps, keeping delegating methods so existing callers keep working.
A kitchen where one enormous drawer holds cutlery, batteries, tax paperwork and the spare keys. Nothing is lost exactly, but every person needing anything must open the same drawer, rummage past everyone else's stuff, and any reorganization affects the whole household.
saying these in an interview costs you the question
- "Any class over N lines is a god object" — size is a heuristic, not the definition
- "We'll fix it with a full rewrite next quarter" — big-bang rewrites lose undocumented rules
- Calling a stateless delegating façade a god object
- Splitting it purely by file size instead of by cohesive field/behavior clusters
- Refactoring it with no tests pinning current behavior