Skip to content

Lazy Class

The code smell in which a class (or function, module, package) carries too little responsibility to justify the overhead it imposes — the defect living in the economy, not the behaviour, so a correct, clearly-named boundary can still be flagged when its carried value fails to clear its enumerable tax.

Core Idea

Lazy class is the code smell in which a component — typically a class, but the diagnosis extends to functions, modules, and packages — exists while carrying too little responsibility to justify its overhead. Every abstraction has a cost: a name to learn, a file to navigate, an interface to keep stable, a test surface. When earned value (complexity hidden, reuse enabled, a concept named, a contract enforced) falls below that overhead, the boundary is anti-economical. The canonical fix is to inline it and delete it.

Scope of Application

Lazy class lives across the code-quality and maintainability subfields of software, recurring at every construct level a codebase exposes.

  • Object-oriented code — wrapper classes forwarding to one implementation; data classes with no behaviour.
  • Functional and procedural code — the inline-function twin: a one-line helper used by one caller.
  • Module and package structure — a single-function module or a package holding one constant.
  • Public-API and plugin surfaces — where the hidden-currency exception lives: a thin boundary kept because an external contract pays its overhead.

Clarity

Naming lazy class makes legible a cost the prevailing instinct treats as zero: abstraction has a price that must be earned. It decouples the defect from the question reviewers usually ask — a lazy class can be perfectly correct and clearly named and still be a defect, because the flaw is in its economy. It also gives abstraction-sizing two poles instead of one: lazy class at the low end, god class at the high end, with a healthy abstraction occupying the middle band of responsibility.

Manages Complexity

Judging whether each small component earns its place is otherwise an open, criterion-less debate, so reviewers reach for correctness and naming, which a thin abstraction can satisfy while still being a defect. Lazy class compresses that to one quantity: the ratio of responsibility carried to overhead imposed. It then gives the problem a single axis with two poles, so placing a component reads off a short decided menu — inline, merge with a sibling, grow deliberately, or keep for an external constraint — rather than relitigating each case.

Abstract Reasoning

The smell licenses a diagnostic on economy, not correctness — inferring whether carried responsibility clears the enumerable tax and flagging a defect even when the code works and reads fine. Its boundary-drawing move places a component on the single responsibility axis (lazy versus god class) to select its fix, and discriminates lazy class from its neighbours (lava flow, speculative generality) by mechanism. Its interventionist move defaults to inlining but requires a hidden-currency check — a stable API, plugin seam, or versioning boundary paying overhead in an invisible currency.

Knowledge Transfer

Within software the smell transfers as mechanism across all code-quality work and every construct level — class, function, module, package are one diagnosis at different granularities, with the responsibility axis, fix menu, and hidden-currency exception carrying intact; the vocabulary (Fowler's inline-class, code smells, responsibility-driven design) is software-internal but fully portable. Beyond software the general balance recurs — ceremonial offices, redundant statutory clauses, thin curriculum units — but "lazy class" does not transport: the diagnosis lands under parent primes abstraction, parsimony, and minimalism, while the named smell stays software's version of the balance.

Relationships to Other Abstractions

Local relationship map for Lazy ClassParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Lazy ClassDOMAINPrime abstraction: Economies of Scale — is a decomposition ofEconomiesof ScalePRIMEDomain-specific abstraction: Code Smell — is a kind ofCode SmellDOMAIN

Current abstraction Lazy Class Domain-specific

Parents (2) — more general patterns this builds on

  • Lazy Class is a kind of Code Smell Domain-specific

    Lazy Class is the code-smell species whose low responsibility-to-overhead ratio suggests that an abstraction boundary has not earned its maintenance cost.

  • Lazy Class is a decomposition of Economies of Scale Prime

    Lazy class is the software-boundary case in which fixed abstraction overhead is spread over too little carried responsibility to reach an efficient scale.

Hierarchy paths (6) — routes to 6 parentless roots

Neighborhood in Abstraction Space

Lazy Class sits in a crowded region of the domain-specific corpus (28th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Adversarial Exploits & Structural Boundaries (12 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12