How using design patterns is like baking a loaf of bread
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on August 16, 2013 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
There’s a great little book that’s a must-have for every aspiring chef, called Ratio. It’s written by a man named Michael Ruhlman, and the point of the book is that many basic cooking concepts can be broken down into a ratio that any chef can apply and come up with a delicious pastry, stock or cake.
The point of the book is that recipes don’t matter as much as understanding the basics of how those recipes are created. In fact, the book contains only one or two recipes for each specific type of item; the rest of it dedicated to explaining how the ratio works. Yet the outcome is quite powerful: knowing that 1 part sugar to two parts fat to three parts flour makes a serviceable cookie or that five parts flour and three parts liquid (plus yeast and salt) makes a decent loaf of bread opens a world of possibilities to someone willing to experiment.
So what’s the point? And how does this relate to design patterns?
Design patterns and ingredient ratios are very similar to one another; specifically, neither is a specific recipe for accomplishing a particular task. Instead, both are frameworks that establish basic levels of understanding for creating something grand.
Wikipedia defines a design pattern as follows:
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
Unpacking this definition a little bit, we can easily see three basic points here:
- Design patterns are frameworks, not finished products.
- The specific implementation of the pattern is up to the developer.
- Design patterns highlight things developers have been doing and codify the best practices of those behaviors.
Design patterns are essentially ratios for creating applications. They describe relationships, but do not themselves act as code. Just like 5 parts flour : 3 parts liquid may describe how to create a loaf of bread, which liquid is up to the cook. Water? Milk? Cream? Beer? Melted butter? Similarly, the yeast and salt content is left up to the chef as well; bread won’t rise without yeast or taste good without salt. And design patterns won’t work without a developer writing the code to use them.
Design patterns scare developers because they think that unless they follow a design pattern exactly they can’t be doing it right. I’m here to tell you that’s hogwash: design patterns are no more concrete than ratios for baked goods. The grandeur is in the implementation, not the framework. So go out and experiment.
Sure, maybe some of your finished products won’t “taste good.” But that’s part of learning too. Keep at it – one day they’ll taste great!
Write better object oriented PHP today.
Object oriented programming always leaves you with a headache. What if you could master it instead?Get the book now! »