June 3, 2011

What My Local Sandwich Shop Taught Me About Design Patterns

Where I live, there are a few regional sandwich shop chains that I like to frequent. These shops make and serve all kinds of sandwiches, both hot and cold, along with various appetizers and side dishes. I was perusing the menu of one of my local favorites when I had an epiphany about software design patterns!

You see, these shops actually have names for their sandwiches. When you walk in, you'll hear customers asking for an "Imperial", a "Special", or an "Italian, without the hots." Each of these names relates to a sandwich that is composed of specific meats, cheeses, and other toppings, and is served on a particular type of bread. For instance, a "South Philly" consists of:

  • Prosciutto
  • Genoa Salami
  • Capocollo [sic]
  • Roasted Red Peppers
  • Sharp Provolone
  • Lettuce
  • Tomato
  • Seasonings
...and a choice of additional toppings:
  • Oil
  • Mayonnaise
  • Onions
  • Hot Peppers
...and is served on a seeded roll.

Now, I want you to imagine that every time you walked into my local sandwich shop, you had to order a sandwich like the South Philly by its ingredients. Every. Time. How likely is it that you'd keep ordering that sandwich? How likely is it that the staff would consistently get your order right?

You see, naming a sandwich like the South Philly is not just clever marketing, it's a vital communication tool for both customers and restaurant staff alike. When a customer orders a South Philly, s/he doesn't have to worry about the details of what's on the sandwich. Similarly, when the order is passed on to the staff, they know precisely what to make. By naming their sandwiches, my local sandwich shop has reduced the complexity of ordering for the customer, and has also reduced the complexity of communicating among the shop staff about each order. As a result, customers more often get the sandwiches exactly the way they ordered them, and there is more consistent communication among staff about each order. The shop earns a good reputation for its service, and customers keep coming back to order more Imperials, Italians, and South Phillys.

So, what does all this have to do with software design patterns?

You see, when I was first introduced to design patterns, my implicit assumption was that they represented a sort of solution template for certain types of software design problems. Of course, this assumption is correct, however it's only part of the equation.

Like the sandwiches at my local sandwich shop, design patterns have names as well: "Facade", "Adapter", "Bridge", "Observer", "Decorator", and so on. Also like my local sandwich shop, these names represent a set of "ingredients" for each pattern: Problem Statement, Constraints, Solution, Collaborators, etc. Imagine if we had to specify every component in a pattern while communicating with other members of our teams about our software designs -- what do you think the results would be? Would we have fewer or more design defects? Would we have fewer or more implementation defects? Would the quality of the final software product be better or worse?

Design patterns are not just a way of solving certain software design problems; they are also a way of communicating about the solutions to those design problems in which there is reduced complexity and greater consistency in communication. When I say to my team, "I'd like to wrap our BLL API in a Facade," we all understand what that means, which allows us to produce exactly the software that our clients expect with a minimum of defects or other problems. Our shop earns a good reputation for its service and quality products, and customers keep coming back to order more applications.