Why Design Patterns May Harm Your Projects More Than Help

Reusable Solutions

Design patterns are defined in software engineering as reusable solutions to commonly occurring problems within a specific context. While abstracting from many concrete projects makes summarising patterns relatively easy, applying those abstractions to concrete scenarios is difficult without sufficient experience or thoughtful analysis.

Less‑experienced engineers may understand the examples in the book but cannot leverage them in real projects, whereas seasoned engineers often already know the concepts, rendering the patterns redundant.

Hammer and Nail

Blindly treating the 23 patterns as a universal toolbox can produce legacy code that later engineers must refactor. The author stresses that a pattern is only useful when its limitations and the problem context are clearly understood.

For example, adding replicas and backup servers improves availability by avoiding single‑point failures. While the principle is obvious, implementing multi‑instance deployment or active‑active disaster recovery requires many details—service registration, discovery, load‑balancing, network latency, data consistency—that are omitted from the abstract pattern.

Different programming languages provide alternative ways to realise the same intent. In Objective‑C, the observer pattern can be implemented via Key‑Value Observing rather than the classic class‑based structure:

// Register observer
[self.object addObserver:self
    forKeyPath:@"age"
    options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld
    context:NULL];

// Callback implementation
- (void)observeValueForKeyPath:(NSString *)keyPath
    ofObject:(id)object
    change:(NSDictionary *)change
    context:(void *)context {
    // ...
}

Because object‑oriented languages differ in how they support encapsulation, inheritance, and polymorphism, the same pattern may have multiple implementations, and a naïve copy‑paste can produce odd results.

Common Terminology

Design patterns can improve communication among engineers only when all parties share a correct understanding of the terminology. The 23 patterns can be split into widely understood ones (e.g., Singleton, Abstract Factory) and more obscure ones (e.g., Interpreter, Visitor) that are harder to grasp.

If both sides understand the pattern names, they can quickly convey high‑level design ideas, but detailed knowledge of the implementation remains essential.

Conclusion

Learning design patterns alone does not make one a good software engineer. True design ability comes from continuous reflection on code, recognizing extension points, and crafting appropriate abstractions. The book’s subtitle, "Elements of Reusable Object‑Oriented Software," highlights its focus on OO languages, yet modern languages often support multiple paradigms that can simplify or replace many classic patterns.

Therefore, developers should treat design patterns as a vocabulary rather than a recipe, evaluate their relevance to the specific language and project, and prioritize unit testing and practical experience over rote pattern application.