Destructive Decoupling

You open a file. It's technically perfect. Every dependency is injected. Every implementation hides behind an interface. Nothing is coupled.

Nothing happens either.

The code delegates to an interface. The interface is implemented by a factory. The factory injects a strategy. The strategy is built by a builder.

ProcessorFactory.getInstance()
    .getStrategy(StrategyType.Default)
    .execute(new ContextBuilder().build());

Finding what this code actually does—the part the user cares about—requires jumping through layers of abstraction across many files. That's what happens when decoupling becomes the goal instead of the means.

Coupling isn't inherently bad. Cohesion matters just as much—code that belongs together should stay together. When two pieces of code always change together, separating them doesn't add clarity, it adds distance.

The heuristics tend to be simple. One implementation? You probably don't need the interface yet. Simple constructor works? You probably don't need the factory.

The question isn't "How decoupled is this?" It's "Can someone understand what this does?" If the choice is between a properly decoupled system nobody can follow and a coupled system someone actually can, the readable one wins.