Skip to main content
h1. Object-Oriented Sandwiches -- Part 1 p(meta). Nov 2012 - Grand Rapids Welcome to part one of a series where I'll attempt to explain Object-Oriented Design (OOD) through the metaphor of a fictional sandwich shop. In this part we'll learn about objects and classes, public and private interfaces, and separation of responsibilities. h2. Welcome to the Rubytown Sandwich Shop Bob loves sandwiches. He loves to make them and to eat them, but when he and his wife Jane moved to the tiny hamlet of Rubytown (population 1,024) there weren't any good sandwich shops. To right this terrible wrong, they opened their own shop and have been doing pretty well for themselves. We're going to poke around and see exactly how their shop works and find the many similarities between a successful real-world business and a successful computer program. h2. Making sandwiches RSS is a little place. It holds half-a-dozen tables where people can eat, a counter with a big menu above it where Jane takes people's orders, the kitchen where Bob does his magic and a storeroom/cooler area where they keep pastrami, plastic wrap, and the like. RSS is not just a "thing". It's a collection of things: the dining room, the counter area, the kitchen and the storage area. Each physical area of the shop has its own purpose, and mixing them together would make a big mess. In addition, each area has stuff that lives in it and stuff that happens in it. The dining room has a certain number of tables, chairs, napkins, etc. It also has certain specific acceptable actions that can happen there: walking, eating and talking are OK... skateboarding isn't. A computer program isn't a "thing", either. It's a collection of what we call *objects*. A program's objects should be as distinct and focused in purpose as the areas of the sandwich shop. They have stuff that lives in them -- known as *data* -- and stuff that can happen within them -- which goes by many names depending on context: *actions*, *commands*, *queries* or *methods*. The "stuff that lives in it and stuff that happens in it" applies to the little things around the shop, too. When Bob invents a new sandwich, he writes down a recipe so he can make as many as he wants without thinking too hard. Recipes include ingredients -- pastrami, hot peppers, buns -- and assembly instructions -- slicing, stacking, toasting. Jane writes down and totals the orders the same way every time to keep things moving smoothly up front, as well. In programming, we call a recipe a *class*: it's a set of instructions for the stuff an object can hold and the stuff it can do. To write a program that makes sandwiches, our data would be the bread, mustard, pastrami and the paper to wrap it in. The actions would be things like spreading and slicing. At a larger scale, the blueprints the contractor used to build the sandwich shop are also a list of ingredients and a set of instructions. Objects are nested like layers of an onion, the same way the shop itself holds the four main areas, each area holds smaller components like customers and sandwiches, and each sandwich is made up of bread and fillings. h2. Ordering Sandwiches Bob and Jane are... kind of grouchy. They get on each other's nerves easily, so they have a rule: Bob doesn't tell Jane how to handle the customers, and Jane doesn't tell Bob how to make sandwiches. At the same time, customers are only allowed in the front of the shop, nobody but Jane goes behind the counter, and *nobody* goes in the kitchen but Bob. But along the edges, things get done. The counter is where the dining room and the ordering area connect, so that's where customers place their orders with Jane. The ordering area and the kitchen are connected by a window so Jane can pass through order slips and Bob can pass out sandwiches. Objects should be arranged the same way. Objects communicate at their edges -- known as their *public interfaces*. We call it a "public" interface because that's the part that other objects get to see and talk to. Customers know they can give Jane the name of a sandwich and some money, and she'll give them a sandwich. Jane knows she can hand Bob an order slip and she'll get a sandwich back. But if there are public interfaces, there must be *private interfaces*. Jane can't tell Bob how to make a sandwich (unless she's in the mood for a screaming match) and the customers aren't allowed to tell Jane how to total up their bill. The details of *how* an object does its job -- its *private interface* -- are nobody else's business. In a computer program, this is one of the most important principles there is: other objects can know *what* an object does -- make sandwiches, take orders -- but *how* the object does it is nobody else's business. This allows the object to do its job -- and *change* how it does its job -- without the public knowing a thing about it. This keeps objects flexible and able to handle the many minor changes that are inevitable over time. h2. Do what you do best On occasion, Bob or Jane gets sick and the healthy one has to run the whole sandwich shop alone. It's always a disaster. Jane forgets ingredients or cuts herself in the kitchen, Bob gets confused trying to make change or gives the customers a hard time when they don't order efficiently. In their own arenas, Bob and Jane are champions, but take them out of their "sweet spot" and they get all confused. It's best when they each stay in their own domain and do what they're best at. Programmers who have programmed in "procedural" languages tend to write code that reads like dance instructions: step forward with the right foot, step out with the left foot, feet together... In running a sandwich shop they might say: take order, gather ingredients, build sandwich, wrap sandwich, ask for money, make change, give sandwich. But you'll notice that this is exactly what happens when Bob or Jane is out sick, and the same chaos and confusion now reigns in our computer program. In programming "do what you do best" is called *SRP*: the *Single Responsibility Principle*. The central idea behind Object-Oriented Design is that each object is designed to do a single thing extremely well and is adamant that nobody pokes around in its business. "You can tell me what you want, but don't tell me how to do it." Which leads us naturally into the subject of communication, the topic of our "next post":/2012/11/16/oo_sandwiches_2.html. h2. Takeaways * Applications are collections of specialized objects that communicate to get a larger task done. * Objects have stuff that lives in them (data) and stuff that can happen in them (methods). * The recipes we use to build objects are called classes. Classes describe the data that lives inside objects and actions that can happen to them, allowing us to easily build as many as we need. * Objects should tell other objects *what* needs to happen (the public interface), but not *how* to do it (the private interface). This allows objects to change their inner workings without forcing other objects to change as well. * Objects should know how to do one thing well and ask other objects to do anything else. This is called the Single Responsibility Principle (SRP) and it keeps each object simple and easy to understand.