As a designer, when should behavior be a static method versus an instance method, and why might over-using static hurt a codebase?

## The design question Given a piece of behavior, should it be a **static method** (on the class) or an **instance method** (on an object)? The answer follows from *what the behavior depends on*. ## When static is the right choice Make it static when the method is, ideally, a **pure function**: its result depends only on its arguments, it touches **no per-object state**, and (ideally) has no side effects. - **Utility helpers**: `Math.max(a, b)`, `Collections.sort(list)`, `Objects.requireNonNull(x)`. - **Factory methods**: `List.of(...)`, `Optional.of(...)`, `Instant.now()` — they create and return objects. - **Stateless conversions/validation**: parsing, formatting, math. - **Constants**: `static final` shared immutable values. These share a trait: there is no object whose data they need, so attaching them to an instance would be noise. ## When an instance method is the right choice Make it an instance method when the behavior: - **Reads or mutates the object's own fields** (`account.deposit(amt)` changes *this* account). - **Should differ by subtype** via **polymorphism** — only instance methods are overridable and dynamically dispatched. Static methods are *hidden*, not overridden, and bound to the declared type at compile time. - **Collaborates with injected dependencies** that you want to configure or replace. ## Why over-using static hurts ### 1) Untestable / unmockable A static call like `PaymentGateway.charge(...)` is hard-wired at compile time. You can't inject a fake gateway for a unit test without bytecode tricks; the dependency is invisible in the constructor. Instance methods behind an interface can be stubbed trivially. ### 2) No polymorphism / no extension Because static dispatch uses the *declared* type, you can't override a static method to specialize behavior. This blocks the Open/Closed principle and strategy-style substitution. ### 3) Hidden global coupling Static methods that read static state introduce *invisible* dependencies — a caller has no idea it depends on global state until it breaks. This is the opposite of explicit dependency injection. ### 4) God-class drift Static 'Utils'/'Helper' classes have no cohesion pressure, so unrelated methods pile up, and everything depends on the dumping ground. ## The reconciling rule Modern Java leans on **dependency injection**: behavior with collaborators or config lives on **injectable instances** (often behind interfaces), enabling testing, substitution, and polymorphism. Reserve `static` for **stateless, dependency-free, side-effect-free** operations and **immutable constants**. **Heuristic:** *If you would ever want to substitute it, override it, stub it in a test, or vary it by configuration, it should not be static.* If it's a pure helper that will never need any of that, static keeps it simple and discoverable. ## Nuance: static factory methods are a sweet spot Static *factory* methods (`of`, `valueOf`, `from`) are widely endorsed (e.g., Effective Java) precisely because they're stateless creators that can return cached or subtype instances — a controlled, beneficial use of static that doesn't carry mutable global state.