Pattern overuse & anti-patterns

A gallery of anti-patterns

An anti-pattern is a solution that looks reasonable, gets used a lot, and reliably makes things worse. Most pattern misuse falls into a handful of recognizable shapes. Learn to spot these on sight — in your own diffs and in code review.

1 · Singleton abuse — a global variable in a tuxedo

The [[singleton]] gives you one instance with a global access point — and that global access is exactly the trap. Any code, anywhere, can call Config.getInstance(), so dependencies become invisible: a class secretly reaches out and grabs what it needs instead of being handed it. That makes it hard to test (you can't swap in a fake), hard to reason about (who touches this?), and quietly couples half your codebase to one object.

// SMELL: hidden dependency, global reach-out, untestable
class OrderService {
  save(o: Order) {
    Database.getInstance().insert(o);  // where did this come from?!
  }
}

// FIX: inject it — the dependency is now visible and swappable
class OrderService {
  constructor(private db: Database) {}   // handed in, not grabbed
  save(o: Order) { this.db.insert(o); } // a fake DB slots in for tests
}

The fix is almost always the same: inject the dependency instead of grabbing a global ([[dependency-injection-and-ioc]]). You keep "one instance" if you truly need it — you just pass it in rather than letting every class summon it from the ether.

2 · Speculative generality — abstraction nobody asked for

This is the purest form of pattern overuse: an interface with exactly one implementation, a Factory that only ever builds one type, a base class with a single subclass, "configurable" knobs no caller ever turns. It was all added "in case we need it later." Every one of these is a layer of indirection you pay for now — more files to open, more hops to trace — buying flexibility you aren't using.

• interface IPriceCalculator with one class PriceCalculator — the interface is dead weight until a second implementation exists.
• A WidgetFactory.create() that always returns new StandardWidget() — the factory adds a hop and decides nothing.
• A method that takes a strategy parameter that's always the same value at every call site.

3 · The God object — one class that does everything

A Manager or Utils or Application class that grows to 2,000 lines and touches everything: parsing, validation, database, formatting, networking. It violates the Single Responsibility Principle ([[single-responsibility]]) — it has a dozen reasons to change, so every change risks breaking something unrelated. Nobody can hold it in their head, and two people can't work near it without colliding. Fix: split it along its responsibilities into small classes that each do one thing.

4 · Poltergeist — the class that just forwards

A Helper, Wrapper, or Manager whose every method does nothing but call another object's method and return the result. It adds a name and a file but no behavior — a ghost in the call stack. You trace a call through three classes only to find the third one does the actual work. If a layer only forwards, delete it and call the real thing directly.

5 · Golden hammer / pattern-itis — forcing a favorite

You just learned Strategy, so now everything is a Strategy — even a tax rate that has been 0.2 since the company was founded. This is the "when you have a hammer, everything's a nail" trap: applying one beloved pattern everywhere regardless of fit. Its worst form is the AbstractFactoryFactory — patterns stacked on patterns until the ceremony dwarfs the work. A constant doesn't need a Strategy. A single object doesn't need a Factory. Match the tool to the force, not to your enthusiasm.

6 · Event soup — premature Observer / indirection overload

Everything fires events; everything listens; and now no one can answer "what happens when I click Save?" by reading the code — the flow scatters across a dozen handlers that trigger each other. [[observer]] and event buses are powerful, but heavy indirection has a cost: control flow becomes invisible. Use direct calls until decoupling buys you something real (a truly varying, runtime set of listeners). If a straight-line function would do, write the straight-line function.

How to apply patterns wisely

1. Start simple. Write the most direct code that solves today's problem — the plain function, the direct call, the concrete class. Ship it.
2. Wait for the pain. Let duplication or a rippling change reveal itself. The rule of three: the first time, just write it; the second time, note the duplication; the third time, refactor.
3. Refactor TO the pattern. When the pain is real and repeatable, introduce the pattern to relieve it — shaped by the actual cases you now have, not guesses.
4. Prefer the smallest pattern. A function beats a Strategy class; a plain object beats a Factory. Choose the least machinery that removes the pain.
5. Delete abstractions that never earned a second implementation. An interface, factory, or base class that's had one concrete use for a year isn't flexibility — it's cost. Collapse it.

// OVER-ENGINEERED: a pattern for a value that never varies
interface IGreeter { greet(name: string): string; }
class EnglishGreeter implements IGreeter {
  greet(name: string) { return "Hi " + name; }
}
class GreeterFactory {
  static create(): IGreeter { return new EnglishGreeter(); } // only one!
}
const msg = GreeterFactory.create().greet("Ada");  // 3 files, 1 behavior

// HONEST: the whole job, no ceremony
function greet(name: string) { return "Hi " + name; }
const msg2 = greet("Ada");                           // 1 line, same result

Signs you actually NEED a pattern...

• A change keeps rippling — the same edit forces you to touch three, four, five places every time. That duplication of change is the clearest call for structure.
• You genuinely swap implementations — there are already two or more real variants (payment providers, export formats, storage backends), not one plus a hypothetical.
• A class has grown many reasons to change — it's clearly doing several jobs and every edit is scary. Splitting along responsibilities is overdue ([[single-responsibility]]).
• You hit the pattern's exact problem — you can name the force in one sentence: "this must vary at runtime" ([[strategy]]), "one object changes and many must react" ([[observer]]).

Signs you're over-engineering...

• Your reason starts with "what if someday..." — you're building for an imagined future, not a present pain. That's speculative generality, a YAGNI violation.
• An interface, factory, or base class has exactly one implementation — and has for a while. It's indirection with no payoff; collapse it.
• You're reaching for a pattern because you just learned it — the golden-hammer reflex. Fit the tool to the force, not to your excitement.
• A reader can't trace the flow — Managers forward to Helpers that fire events into a bus. If the indirection buys nothing, the straight-line version is better code.