Lazy Class is a code smell where a class does so little work that it no longer justifies the cognitive overhead and structural complexity of its existence — typically a class with one or two trivial methods, a minimal set of fields, or functions primarily as a passthrough that delegates to another class without adding any meaningful logic, abstraction, or value of its own.

What Is a Lazy Class?

Lazy Classes appear in several forms:

• Thin Wrapper: A class with 2 methods that simply call into another class, adding no logic, error handling, or transformation.
• One-Method Class: A class containing a single execute() or process() method that could instead be a standalone function or merged into its only caller.
• Speculative Class: A class created in anticipation of future requirements that never materialized — "We might need a CurrencyConverter someday."
• Refactoring Remnant: A class that was rich before a refactoring moved most of its logic elsewhere, leaving a skeleton behind.
• Data Holder with No Behavior: A class storing two fields with getters/setters that is too simple to warrant a class — a Coordinate holding just x and y might be better as a named tuple or record in many contexts.

Why Lazy Class Matters

• Cognitive Overhead: Every class in a codebase is a concept a developer must learn, remember, and reason about. A lazy class imposes this cognitive cost while providing negligible value. A codebase with 50 lazy classes has 50 unnecessary concepts cluttering the mental model of the system.
• Navigation Friction: Finding functionality requires searching through class hierarchies, imports, and module structures. Unnecessary classes add layers of indirection without adding clarity. A developer debugging a call chain who must navigate through a class that does nothing but delegate loses time and flow.
• Maintenance Surface: Every class requires maintenance — it must be updated when its dependencies change, understood during refactoring, included in documentation, and covered by tests. A lazy class that contributes no logic still incurs all these costs.
• False Abstraction: Lazy classes sometimes suggest an abstraction boundary that does not actually exist. UserDataAccessLayer that has three methods directly wrapping UserRepository methods implies a meaningful separation that does not exist in practice.
• Package/Module Bloat: In systems organized by packages or modules, lazy classes inflate the apparent complexity of those modules, making architectural diagrams less informative.

How Lazy Classes Form

• Over-Engineering: Developers create abstraction layers prematurely, anticipating complexity that never arrives.
• Refactoring Incompletion: After extracting logic elsewhere, the now-empty class is not removed.
• Framework Mandates: Some frameworks require certain class types (e.g., empty controller classes in some MVC frameworks) — these are framework-mandatory skeletons, not true lazy classes.
• Team Conventions: Teams that mandate a class for every concept sometimes create classes for concepts that are too simple to warrant them.

Refactoring: Inline Class

The standard fix is Inline Class — merging the lazy class into its primary user or deleting it:

1. Examine what methods the lazy class provides. 2. Move those methods directly into the class that uses them most. 3. Update all references to call the inlined class directly. 4. Delete the empty shell.

For speculative classes that were never used: simply delete them. Version control preserves the history if they're needed later.

When Lazy Classes Are Acceptable

• Explicit Extension Points: A nearly empty base class designed as an extension point for future subclasses (Strategy, Template Method pattern skeleton).
• Interface Implementations: A class that exists primarily to satisfy an interface contract for dependency injection, where the null-implementation pattern is intentional.
• Framework Requirements: Some frameworks require specific class structures that may appear lazy but serve the framework's lifecycle management.

Tools

• SonarQube: Detects classes below configurable complexity thresholds.
• PMD: TooFewBranchesForASwitchStatement, low method count rules.
• IntelliJ IDEA: "Class can be replaced with an anonymous class" and similar hints.
• CodeClimate: Complexity metrics that flag very low complexity classes.

Lazy Class is dead weight in the architecture — a class that occupies structural real estate in the codebase without contributing corresponding value, imposing cognitive and maintenance costs on every developer who must navigate past it to understand the system's actual behavior.