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

BobDalgleish
  • 4,644
  • 5
  • 18
  • 23
Tim
  • 5,405
  • 7
  • 48
  • 84
  • 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. – Robert Harvey Dec 16 '19 at 21:35
  • 6
    Yes. I read your comment too, but I don't understand it – Tim Dec 16 '19 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. – Robert Harvey Dec 16 '19 at 21:41
  • 3
    Can you be more accurate and general? I don't understand your example – Tim Dec 16 '19 at 21:43
  • Basically, the file system should still function regardless of the permissions you hand to it. It's kinda like the separation between code and configuration; you don't want to bake decisions into the code that could be made using a configuration file instead. – Robert Harvey Dec 16 '19 at 21:47
  • 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 '19 at 12:15

3 Answers3

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.

Eric Lippert
  • 45,799
  • 22
  • 87
  • 126
  • 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 '19 at 00: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! – Eric Lippert Dec 17 '19 at 00:25
  • @Tim: And yes, being able to re-use the same mechanism in multiple places is a great benefit; it is precisely because mechanisms fulfill their contracts independent of the policies they implement that makes them reusable. If you have a list that *knows* that it is for thread scheduling then you cannot use that list for any other task. – Eric Lippert Dec 17 '19 at 00:27
  • Is the purpose of separating policy and mechanism, simply to make mechanism reusable across policies? Is its purpose to let policy and mechanism vary independently of each other, just like separation between interface and implementation is to let interface and implementation vary independently of each other? – Tim Dec 17 '19 at 00:53
  • Though the reuse angle is a good one, it's not the *only* good reason. Think also about it from a change management perspective. Suppose every time you wanted to change the speed limit on a road you had to update software running in the *wheels* of every car. That would make policy changes expensive, time-consuming, and dangerous. The same is true in software. We want policies to be isolated to code that is *just about policy* so that when a policy changes -- as they often do -- that we are updating code in a clear place that will not affect other mechanisms. – Eric Lippert Dec 17 '19 at 01:04
  • The mechanism of disk I/O libraries include the capability to wipe the entire drive. It is the policy of my app to avoid actually doing it. – Abion47 Dec 17 '19 at 23:50
  • @EricLippert I'm late to the party, but you're explaining this wonderfully, and it's finally starting to click. Question: it sounds like "separation of policy/mechanism" is *the* criterion for good abstraction. Is that a fair assessment, or it too reductive? – Louis Thibault Feb 26 '21 at 02:27
  • 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. – Eric Lippert Feb 26 '21 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. – Eric Lippert Feb 26 '21 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". – Louis Thibault Feb 26 '21 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.

JimmyJames
  • 24,682
  • 2
  • 50
  • 92
  • 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 '19 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 '19 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 '19 at 22:32
  • 1
    Isn’t there a taste of Wonderland in this answer, Alice ? ;-) – Christophe Dec 17 '19 at 08: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 '19 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.

supercat
  • 8,335
  • 22
  • 28