16

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.)

6
  • Have you read the rest of the Wikipedia article? If you read a bit farther, you discover that the principle essentially allows a system (a mechanism) to function properly without being forced down a specific policy path. AFAICT this doesn't have anything to do with SOLID. Dec 16, 2019 at 21:35
  • 6
    Yes. I read your comment too, but I don't understand it
    – Tim
    Dec 16, 2019 at 21:38
  • Imagine a file system that allows you to read a file but not write it. The file system is the mechanism. The policy is read-only. The separation of mechanism and policy allows the file system to still work. Dec 16, 2019 at 21:41
  • 3
    Can you be more accurate and general? I don't understand your example
    – Tim
    Dec 16, 2019 at 21:43
  • 1
    Policy is a config file. This is almost the same as saying: do not hardcode program settings. For example, when designing a firewall you DONT create one where you blacklist an array of IP addresses because that hardcodes policy into code - that a firewall is a blacklist. You don't implement a whitelist either. Instead, a well designed firewall allows the user to either blacklist or whitelist address ranges (or both depending on more complex conditions) because the decision to blacklist or whitelist is policy - which should not be part of the mechanism
    – slebetman
    Dec 17, 2019 at 12:15

3 Answers 3

41

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.

10
  • Thanks. (1) Separation between policy and mechanism is used in several different places in OS design. I saw it is mentioned in Modern OS by Tanenbaum. Does "policy code describes what the code does in the level of the business domain" (and its implication that mechanism is at a business-unaware domain) still apply to the examples in OS design? (2) Can a policy implemented in terms of more than one mechanisms at the same time? Are mechanisms common building blocks that can be used in implementations of different policies?
    – Tim
    Dec 17, 2019 at 0:09
  • 1
    @Tim: There is nothing particularly special about operating systems. If your policy is "the blocked thread that has been waiting the longest gets woken up first" then that policy can be expressed independently of whether the list of sleeping threads is implemented as an array, a heap, or a balanced binary tree; the choice of mechanism might have performance implications, but the code that balances the binary tree does not need to know that it is doing so to implement a wakeup policy! Dec 17, 2019 at 0:25
  • 1
    @blz: Thanks for your kind words; I'm glad this is helpful. I would say that separation of mechanisms from policies is certainly an important criterion for a good abstraction; an abstraction is "leaky" to the extent that it fails to do so. However it is not the only important criterion. An abstraction that fails to expose clearly the business domain elements that are important to the user, or exposes too many irrelevant details, is a bad abstraction even if it does not expose mechanisms. Feb 26, 2021 at 17:02
  • 1
    @blz: For example, imagine your standard "employee" abstraction common in business software. An abstraction that, say, exposes the medical history of employees regardless of whether the payroll system developer is authorized to see that, or regardless of whether that is relevant to payroll, might expose no details of the database query mechanisms underlying the abstraction, but still would not be a "good" design. Feb 26, 2021 at 17:04
  • 1
    @EricLippert, ah yes, that's a very good point! It seems like it would be correct to say "the purpose of an abstraction is to allow the caller to implement policy". It also seems correct to say "abstractions should hide mechanism (and do other things too)". Policy should be encoded in the form of abstract logic. I may be overthinking this, but I'm struggling to bridge the conceptual gap from "I know the definition" to "I can recognize it when I see it" to "I can creatively use it myself". Feb 26, 2021 at 19:01
14

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.

5
  • Which is changed more frequently over time, policy, mechanism, or both? Is the principle of separating policy and mechanism to make change to one not affect the other? (Separating interface and implementation allows change to implementation without affecting interface and therefore without affecting client.)
    – Tim
    Dec 16, 2019 at 22:22
  • 2
    Policy typically changes more than mechanism. For example, the role/permission configuration for files changes very often. A new kind of permission option on the file system is rare indeed. Changes to policy always affect the enforcement. Changes to the enforcement options require changes in the policy management. If I wanted to swap out the policy system for one that interacts in the same way with the enforcement, I need to separate the interface of my mechanism from it's implementation. It is not inherent in the policy/mechanism separation.
    – JimmyJames
    Dec 16, 2019 at 22:31
  • What is the purpose of separating policy and mechanism, if it doesn't make change to one not affect the other?
    – Tim
    Dec 16, 2019 at 22:32
  • 1
    Isn’t there a taste of Wonderland in this answer, Alice ? ;-)
    – Christophe
    Dec 17, 2019 at 8:37
  • 1
    @Tim The mechanisms of enforcement are typically very rigid. Take security for example: you need your enforcement of access rights to be rock solid. Policy is very fluid. The person who had access yesterday might not have access today. Solving these two kinds of problems together in one place is problematic. You can do it but it will likely be a buggy mess. Separating policy and implementation does allow for interchangeability but it's a different concept.
    – JimmyJames
    Dec 17, 2019 at 15:47
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.