What does "refactoring away from a pattern" mean, what signals tell you a pattern is over-applied, and how would you safely remove one from a live codebase?

## Why the direction exists Patterns are a *purchase*: you pay indirection, extra types, more files, longer stack traces, and slower comprehension, in exchange for a specific flexibility. Requirements change; sometimes the flexibility was never used, or the reason evaporated (the second payment provider was never built; the plugin marketplace was cancelled). Keeping the pattern then means paying rent on an asset you don't use. Kerievsky's contribution over pure pattern advocacy is making removal a *named, legitimate move* with the same mechanical discipline as introduction — Fowler's catalog contains the machinery (Inline Function, Inline Class, Collapse Hierarchy, Remove Middle Man, Replace Superclass with Delegate/inverse). ## Concrete over-application signals | Signal | What it usually means | |---|---| | Interface with exactly one implementation, unchanged for a long time | Speculative generality; the seam was never needed (mock-only implementations don't count as a second implementation) | | Factory/Builder that always returns the same concrete type with the same arguments | Creation logic has no variation to encapsulate | | Singleton accessed statically from everywhere | Global mutable state in disguise; hidden dependency, test-order coupling | | Every feature change touches 4 files across layers | Indirection exceeds the variation it serves | | Wrapper/decorator layer present in 100% of compositions | Not optional — belongs in the core | | Observer/event indirection with a single, synchronous, always-registered listener | A direct call would be clearer and debuggable | | Visitor over a hierarchy that hasn't changed in years and whose operations rarely grow | Cost of the double-dispatch machinery isn't repaid | | Abstract base class with one subclass | Collapse Hierarchy candidate | **Important caveat:** "only one implementation" is evidence, not proof. Legitimate reasons to keep a lone abstraction: an architectural port at a module/hexagonal boundary you deliberately enforce; a published extension point with external implementers; a dependency-inversion seam that keeps a domain module free of infrastructure; enforced compile-time module boundaries (as in Spring Modulith-style `*Api` surfaces). Judge by whether the boundary is *load-bearing*, not by counting classes. ## Safe removal procedure 1. **Confirm the assumption.** Search all usages including reflection/DI configuration, string-based wiring, serialized type names, and other repositories. Check telemetry/feature flags to be sure the alternative path is dead. 2. **Check the blast radius.** Internal-only? Refactor freely. Published to other teams/artifacts? Deprecate first, ship a shim that delegates, migrate consumers, then delete — a removal you can't coordinate is a breaking change, not a refactoring. 3. **Strengthen tests** on the behavior the pattern currently produces, at the level that will survive the change (test through the public entry point, not through the class you're deleting). 4. **Inline in small steps**, e.g. for a one-implementation Strategy: (a) make the context depend on the concrete class instead of the interface; (b) inline the delegating call; (c) move the implementation body into the context, or keep the class but drop the interface; (d) delete the interface; (e) simplify the wiring/factory; (f) delete the factory if it now does nothing. For a Singleton: (a) add a constructor and instance methods; (b) convert call sites to injected dependencies one at a time; (c) delete the static accessor last. 5. **Commit per step.** Small commits mean cheap reverts and a reviewable history. 6. **Delete dead tests** that only exercised the removed indirection, and keep the behavioral ones. ## Judgment: when to leave it alone Removal is itself a cost (review time, merge conflicts, risk, churn in blame history). Prefer to remove when: the code is being touched anyway for a feature; the indirection is actively slowing comprehension or onboarding; or it blocks a needed change. Avoid opportunistic mass removals across code nobody is working in — that is the mirror image of pattern-happiness, *refactoring-happiness*, and it burns the same budget with no user-visible return. ## What to say in an interview "I treat patterns as reversible. If an abstraction has one implementation, no external implementers, and hasn't varied, I'll inline it in green steps while I'm in that code — unless it's a deliberate architectural boundary, in which case its value is enforcement, not variation."