How using design patterns is like baking a loaf of bread

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!

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Jeremy Lindblom (@jeremeamia) wrote at 8/16/2013 9:44 am:

Do you think it is useful to try and standardize some of the “ingredients” to design patterns. There are definitely some patterns that are more abstract (chain of command, abstract factory) and some that end up having consistently similar implementations (visitor, observer). To me it would seem helpful to have a library of interfaces and/or traits that can be used as a basis. I started a project on GitHub a while back to capture some of my ideas regarding this concept: https://github.com/jeremeamia/php-design-patterns. I’d be curious to hear some of your thoughts (both in general and about anything specific in that repo if you get the chance).

Larry Garfield (@Crell) wrote at 8/19/2013 1:12 am:

The cooking analogy for design patterns is a good one. Anthony Ferrara and I took a sweeter spin on the same concept a while back: https://www.youtube.com/watch?v=AsfM6YLtu9g :-)

Brandon Savage (@brandonsavage) wrote at 8/19/2013 7:19 pm:

You’re right: some patterns have more standard “ingredients” than others (see Singleton, for example). Just like a loaf of bread requires flour as a basic ingredient, some patterns require similar ingredients while others are more abstract. That being said, I think the SPL does a good job in standardizing some common PHP patterns.

In terms of creating common interfaces, because design patterns aren’t a “type” specifically, interfaces seem challenging. But traits does help solve that to some degree, and I think your project is certainly innovative and unique. I’ll definitely check it out.

Nelson (@nelson_senna) wrote at 8/20/2013 1:41 pm:

One of the main points of Refactoring to Patterns is that implementations really can be different and the book exemplifies it. The book also emphasizes that you should read implementation notes of GoF book to see that there are alternatives to their “sample” implementation. Keep the good work, Bradon! :)

Copyright © 2023 by Brandon Savage. All rights reserved.