In this post I want to cover the general what and why of design patterns. Design patterns are popular, well-supported recipes for writing code. Sticking to a design pattern, as opposed to going completely freestyle can have a number of benefits. Arguably the most important advantage to using a design pattern is the larger community support that they engender: These patterns stick to a known structure, which is more readily communicated, and tend to follow best-practices. Furthermore, the structure they provide often helps prevent making costly mistakes with consequences further down the line. This can be contrasted with so-called “anti-patterns”, which true to their name go against the main advantages of following a design pattern. This includes such sins as namespace pollution, using less efficient non-native methods, and inline script.
Although there is always a kind of specificity in any code, after all we want solutions not just good practices, there are a few commonalities when it comes to writing a true design pattern. These include:
- The practicality of the solution,
- How well it follows best practices,
- How easily a newcomer can come to grips with the pattern.
The latter point naturally leads to a strong emphasis on good documentation and community support, which is something of a virtuous circle. In other words, a design pattern is only a pattern in so far as it follows a solid set of principles.
I hope to work my way through a high-level overview of some of the more popular design patterns in the coming months.
All the best,
Tom