What is separation between policy and mechanism?

Question

The Wikipedia article on separation of mechanism and policy says

The separation of mechanism and policy is a design principle in computer science. It states that mechanisms (those parts of a system implementation that control the authorization of operations and the allocation of resources) should not dictate (or overly restrict) the policies according to which decisions are made about which operations to authorize, and which resources to allocate.

1. What is difference between the design principle of separation of mechanism and policy and the principle of separation of interface and implementation (as in SOLID)?

2. Is a policy an interface?

3. Is a mechanism an implementation of a policy?

4. Which is changed more frequently over time, policy, mechanism, or both?

5. Is the principle of separating policy and mechanism to allow policy and mechanism to change independently of each other? (Separating interface and implementation allows change to implementation without affecting interface and therefore without affecting client.)

Answer 1

What is difference between the design principle of separation of mechanism and policy and the principle of separation of interface and implementation?

They have nothing to do with each other, so it is difficult to describe what the difference is between them.

Separation of interface and implementation is "I don't need to know how the car works in order to drive it". If you know how to drive a gas-powered front-wheel-drive hatchback, and you are asked to drive an electric rear-wheel-drive coupe, the performance characteristics might be different than you are used to, but fundamentally you use essentially the same steering wheel and pedals and light switches and whatnot to operate both vehicles, even though their implementation details are completely different. You only notice the difference when you have interactions with the vehicle that have implementation dependencies, like refueling.

Separation of mechanism from policy is that the car is built to go up to 100 miles per hour in any direction it is pointed, and the driver is responsible for going the correct way down the highway in the correct lane at the correct speed, not the car. The policies about what the speed limit is and when you are allowed to turn left are not embedded in the engine except insofar as the engines were designed by people who knew what likely policies would be enacted.

Now you might then wonder what happens when cars become self-driving, and the answer is: we continue to maintain the separation between policy and mechanism in the design of the software. The choices about when to brake and when to accelerate are made by encoding them in policy code that has executive control over the subsystems which steer the car, actuate the brakes, and so on. Those mechanism subsystems do not know or care about policy; they just do what they are told.

I am a strong believer in keeping mechanism code distinct from policy code. Here's another way to think about it: policy code describes what the code does in the level of the business domain. "Produce a sorted list of the last names of all our customers in London" is in the business domain. "Swap these two out-of-order elements in this array" is in the mechanism domain. The mechanism domain implements the policy, but it does not encode the policy. It encodes facts about array elements, not about customer mailing lists. When code mixes the mechanism and policy domains, it gets harder to reason about and maintain.

Answer 2

The concept of separation between policy and mechanism is completely orthogonal to the idea of interface and implementation. Let's take an analogy:

Imagine an executioner, the kind in a hood with a big axe. His job is to lop off heads. But whose heads exactly? That's up to the queen. In this analogy, the executioner is the mechanism, the queen is setting the policy. You don't have the executioner deciding who is executed.

Now the interface for this is that the queen somehow makes her decision known. Perhaps she shouts "off with his head!". That's the interface. Then there's a process by which someone finds the executioner and brings him together with the unfortunate one to do the deed. That's the implementation.

To sum up policy vs. mechanism is about keeping the part of the system that is responsible for making decisions separate from the part that enforces them. Interface vs. implementation is about keeping the way parts of the system communicate with each other separate from how they react to messages from other parts of the system.

Answer 3

Mechanisms must, by necessity, be under the control of people with considerable programming or systems expertise, while policy should be controllable by people who have no such expertise.