Pattern overuse

After reading about design patterns for the first time, many engineers suffer from Pattern Mania: the compulsive urge to shoehorn every pattern into every class. A simple requirement like "multiply price by quantity" suddenly turns into an AbstractPriceCalculatorFactoryProviderVisitor.

Patterns are solutions to specific, recurring design problems. When applied in the absence of the underlying problem, they introduce Accidental Complexity that slows teams down.

The problem

1 // Pattern Overuse Nightmare:
2 // Problem: Add two numbers and print result.
3 class AbstractCalculationStrategyFactory {
4   createStrategy() {
5     return new ConcreteAdditionStrategy();
6   }
7 }
8 class ConcreteAdditionStrategy {
9   execute(a, b) { return a + b; }
10 }
11 // Why not just: const add = (a, b) => a + b; ?

When simple is better: KISS & YAGNI

1. KISS (Keep It Simple, Stupid): Start with the most straightforward implementation that works.
2. YAGNI (You Aren't Gonna Need It): Do not write code for future requirements that may never arrive.
3. The Rule of Three: Refactor toward a pattern when you see the third repetition of a variation, not on the first.

In code

Signs you are over-engineering

• 1-method interfaces with only 1 implementation: If an interface only has FooServiceImpl, delete the interface unless a second implementation or mock genuinely exists.
• Layers of pure passthrough delegation: If Controller -> Service -> Manager -> Helper -> DAO each do nothing but pass the arguments unchanged to the next layer.
• Premature extensibility: Adding plugin hooks and reflection dynamic loading for a feature that only 1 internal team will ever use.

Related patterns

• Pattern Overuse vs Refactoring: Patterns should emerge organically through refactoring, not be pre-imposed upon blank files.
• YAGNI vs Open/Closed: Open/Closed means writing code that can be extended easily; it does NOT mean writing every theoretical extension upfront.