Why Design Patterns Can Overcomplicate Software and How to Avoid Their Pitfalls

Software design, like building construction, requires planning, but unlike strict architectural standards, software design is often subjective and controversial.

Design patterns are considered the “specifications” of software design, yet in the fast‑moving internet era they can cause over‑design, increasing code complexity and maintenance cost, leading some to view them as mere showmanship.

Defects of Design Patterns

Internet applications prioritize easy modification; the Open/Closed Principle and modularization advocated by design patterns favor extensibility but hinder rapid changes, creating conflicts with frequent iterations.

Examples such as the Open/Closed Principle in middle‑platform systems illustrate how adding new requirements can demand extensive refactoring, turning beneficial patterns into burdens.

The Least Knowledge Principle (Law of Demeter) can also lead to excessive abstraction, as shown by procedural versus strategy‑pattern code examples.

// Procedural salary calculation
int performance = 4;
int level = 2;
String job = "engineer";
switch (job) {
    case "engineer":
        return 100 + 200 * performance;
    case "pm":
        // ...
}

// Strategy‑pattern version
int performance = 4;
int level = 2;
String job = "engineer";
Context context = new Context();
context.setPerformance(performance);
strategyMap.get(job).eval(context);

When requirements evolve (e.g., salary depends on both performance and level), the procedural version adapts easily, while the strategy version requires additional parameters and code changes, magnifying modification cost in large systems.

Understandability Issues

Most design patterns rely on advanced language features such as polymorphism, dynamic/static dispatch, etc., which raise the learning curve compared to simple procedural code.

Core Drawbacks Summary

These three defects—conflict with rapid iteration, reduced understandability, and added accidental complexity—make design patterns costly in internet‑scale projects, while procedural code, though simple, suffers from inherent limitations.

Fundamental Flaws of Procedural Coding

Claims that procedural code is “simple, easy to understand, easy to modify” are misleading; large codebases still need patterns for reuse, and lack of consistent structure raises long‑term maintenance difficulty.

Software Complexity

According to Brooks’ “The Mythical Man‑Month”, software complexity consists of essential complexity (business logic) and accidental complexity (poor technical choices). Over‑design adds accidental complexity, but well‑chosen patterns can mitigate it.

Pattern Evolution

Design patterns must evolve with business needs; functional design patterns in Java 8 (e.g., functional strategy) can reduce migration cost during early, unstable phases, later refactored into classic object‑oriented forms.

interface Strategy {
    void doSomething();
}
class AStrategy implements Strategy { /* ... */ }
class BStrategy implements Strategy { /* ... */ }
class AService {
    private Map<String, Strategy> strategyMap;
    public void doSomething(String strategy) {
        strategyMap.get(strategy).doSomething();
    }
}

class AService {
    private Map<String, Runnable> strategyMap;
    static {
        strategyMap.put("a", this::aStrategy);
        strategyMap.put("b", this::bStrategy);
    }
    public void doSomething(String strategy) {
        strategyMap.get(strategy).run();
    }
    private void aStrategy() { /* ... */ }
    private void bStrategy() { /* ... */ }
}

Debuggable Modules

Modules should expose simple interfaces while encapsulating complex implementations, enabling easy debugging and unit testing, as advocated by John Ousterhout’s “deep modules” concept.

Visitor Pattern Example

Using the Visitor pattern to unify traversal of nested form components reduces duplicated procedural code and improves maintainability.

class CountAVisitor extends Visitor {
    public int sum;
    @Override
    public void visitA(ComponentA a) { sum++; }
}
public int countComponentAB(Form form) {
    CountAVisitor aVisitor = new CountAVisitor();
    form.accept(aVisitor);
    return aVisitor.sum;
}

class GetComponentABVisitor extends Visitor {
    public List<Component> result;
    @Override
    public void visitA(ComponentA a) { result.add(a); }
    @Override
    public void visitB(ComponentB b) { result.add(b); }
}
public List<Component> getComponentAB(Form form) {
    GetComponentABVisitor abVisitor = new GetComponentABVisitor();
    form.accept(abVisitor);
    return abVisitor.result;
}

When used consistently, patterns dramatically lower the cost of understanding and evolving large systems, whereas ad‑hoc procedural code leads to duplicated logic, hidden bugs, and stunted growth.

In summary, design patterns are powerful tools to combat software complexity, but they must be applied thoughtfully, evolved with business changes, and supported by debuggable, well‑encapsulated modules to avoid becoming the very “dragons” they were meant to tame.