Politeness

I've been thinking more about the Politeness Principle I mentioned in the last entry, and I think it's pretty descriptive. In this post, I'll illustrate it with an extended metaphor: food service.

First, let's start with a procedural/imperative food service.

Assume for the moment that, in some sort of bizzare Zamyatin fantasy, everyone is identical. The food service folks come to your little cubicle three times a day and stuff food down your throat. You have no say in how much or what you're fed — it is literally stuffed down your throat.

This, as I think we all can agree, is the least polite level of foodservice. It's also basically how most imperative programming styles work: a single process is in control (the program) and it directly modifies data.

Everyone doesn't have to be exactly the same; there can be some variation, as long as it's evident to the program. When people arrive at work, they could receive a colored card, stuck to their forehead, indicating the type of eater they are. A red card, say, might indicate lots of food, while a blue card indicates less food. The food service folks come by, look at the card, and stuff food down your throat.

Now, say you want an amount of food in between the two extremes — or say you're fasting or not hungry that day. You stick a purple card to your forehead.

The food service folks come by, look at your card, and have no well-defined response. If you're lucky, they might get confused and move on to the next person — if you're unlucky, they might stuff all the food down your throat, or remove you from your cube and replace you with a human-shaped stack of mashed potatoes. The foodservice person might even commit ritual suicide at your feet. The behavior, either way, is undefined. In programming, this is called a "tagged type" — it has a tag indicating how it should be dealt with. As in foodservice, a program must be warned of all the possible tags in advance, or undefined (read: usually bad) things may result. Generally this is either lost data, or corrupted data (replaced with mashed potatoes) — or a program crash.

So, we define some new tags for new types of eaters. Say, green for vegetarian, black for fasting, white for no-gluten. Then we need a new color for vegetarian-heavy-eater, no-gluten-heavy-eater, etc. — every combination we want to handle. This will quickly spiral out of control, with the foodservice people needing to carry tomes explaining what to do in any given case. The foodservice job has gotten very complex, because the people are treated as dumb: they are given a tag, and that's the only communication.

At this point, some bright young foodservice luminary might suggest a revolutionary idea: "Why don't we ask the people?" This is basically the paradigm shift that Smalltalk brought to programming: don't put all the intelligence in the process, let the data itself be intelligent. But a first crack at this is almost always wrong.

The foodservice worker arrives at your cube one morning and, without even looking at your tag, says "Would you like one or two helpings of meat?" "Oh, no thanks," you say, and the foodservice worker shoves one helping down your throat. (The vegetarian next door is even less happy about this.) The question was wrong, and you gave an unexpected answer. This is usually what procedural programmers do when let loose in an object-oriented language like Smalltalk: they let the data be intelligent in all the wrong ways.

It's still not very polite. You're not given freedom of choice, and you certainly don't get to eat at your own pace. Sure, you get to answer a question now, but your eating is still being micromanaged.

As a next crack, the foodservice fellow says "Pick one of the items from this list." If one of them suits you, great, and he shoves it down your throat. If none of them are appropriate, well, too bad, you don't get to eat.

A lot of software systems are half-polite. By analogy, the fellow would roll up a buffet of eats, with some prepared dishes and some raw ingredients, perhaps with a small array of cooking utensils. He would wait patiently while you prepared a dish to perfectly suit your liking, or allow you to refuse if you weren't hungry.

And then he would shove it down your throat.

In a slightly more refined system, he would wait until you had prepared the dish, and then move your arm to the fork and guide it into your mouth for each bite. If he were really nice, he would watch for cues (bloating, vomiting) and stop feeding you, but don't count on it.

All this throat-shoving and force-feeding is starting to make you feel a wee bit violated, and that's exactly the term used in software: specifically, this is "violation of encapsulation." Your eating procedures — and, for that matter, your gastrointestinal tract — are your business, and are encapsulated away from the foodservice procedures.

This allows each eater to have variations. Some folks eat slower; some folks (the author included) tend to just tilt the plate back and let the entire meal plummet to its digestive doom. Just as a polite procedure lets you pick and choose your own ingredients, a really polite procedure would just let you freakin' eat.

So, ideally, the buffet would wait as you consumed your meal (or didn't) at your own pace, let you take another helping if required, and then bid you adieu. This would be polite.

The essence of the principle is this:
1. Don't micromanage.
2. Don't poke around in peoples' privates.
3. The easiest way to allow individual variation is to let people do things for themselves.

This can be applied to software design, as I'm doing with Mongoose, by replacing "people" with "software components." In the LinkedList I described in a previous post, I noted that the program doesn't forcefully grab some elements of the list and do actions on them; the process is closer to "Hey, element x, do this, and ask your neighbors to do it too."

As for individual variation, I dropped in an alternative Link implementation, RunLink, that can represent multiple identical elements with a single node. It required no changes to LinkedList, because LinkedList didn't care about the internals of the links — it only sent them messages and worked with their responses.

This is the real power of object-oriented design, and unfortunately it's lost on a lot of folks working in OO. I think it's that they haven't had it explained well. This blog post is off the top of my head, so it continues to be explained poorly, but you get the idea, I hope.