Design patterns are solutions or approaches to situations that appear often when developing software. They were introduced to the software engineering community at large by the seminal Gang of Four (GoF) book, “Design Patterns: Elements of Reusable Object-Oriented Design.” The touted benefits of design patterns are that they allow proliferation of best practices by “codifying” them as design patterns and providing efficient communication between engineers who can refer to an entire design pattern, that can consist of many classes, by its name.
I must admit that I haven’t seen those benefits in practice. There is a small subset of design patterns such as Singleton or Factory that are mentioned often, but those design patterns are typically simple and are self-explanatory???or can be explained by one sentence: Singleton???there can be only one; Factory???makes something. I have read the original GoF book and other books and articles that introduced other design patterns and I either recognized design patterns and themes that my colleagues and I have developed ourselves or didn’t really get them deeply. Much later, after I solved a new problem, in retrospect I realized I had used a design pattern. But, I have never looked at a problem and suddenly proclaim: “Hey, let’s use X design pattern here.”
I’m not sure if my opinion is just based on my experience mostly working for fast-paced startups. It’s possible that in larger enterprise shops, design patterns are a part of the culture and dedicated software architects converse with each other using design patterns. But, I highly doubt it. The main reason is that there are a lot of nuances to real world problem and design patterns, by their nature, are general.
In particular, the more complicated design patterns require various adaptations and often a combination of multiple modified design patterns to construct real world systems. So, what’s the bottom line? I believe design patterns are useful for documenting the architecture of systems. They are also great for educational purposes because they have well defined format and explicitly explain what problem they solve. But, don’t expect them to guide you when faced when an actual problem. If you are stumped and start going over a catalog of design patterns to see if one of them suddenly jump-starts your creativity, you might be sorely disappointed.
