policy and mechanism

I was going through my operating systems textbook and I came across the concept of "separating mechanism and policy". I wasn't sure of what that meant so I checked out wikipedia which I must admit, was not of much help either.

The separation of mechanism and policy[1] 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.

Could someone t开发者_StackOverflow社区one this down, and explain if possible with a few examples what separation of mechanism and policy means in the context of Operating systems?

---

Here is what this means for the X-Windows system.

X-Windows, at the very base level, provides a way of manipulating screen areas called 'windows'. It also provides a way to receive events that happen inside windows.

But X-Windows says nothing about title bars, menus, scrollbars or any of that stuff. It also doesn't say anything about the rules by which a particular application can make its window occupy the whole screen, or when a window has to be moved off the screen. It does provide a way for one application to force other applications to ask it permission before doing things with top-level windows, but doesn't provide any such application as part of the base server.

X-Windows is all about mechanism, not policy.

The policy is provided by the widget toolkit, by the window manager, and by other things added to the system later. Many widget toolkits, for example, use a set of overlapping sub-windows for scrollbars and ask for mouse events for these sub-windows so they can detect click and drag operations and make the sub-windows respond appropriately.

This is why, for example, GNOME and KDE can get along on the same display, and why really old X-Windows programs that know nothing about panels or desktops still work just fine on modern systems.

---

In regard to *nix operating systems, the general idea is the security system is implemented by the kernel, and the authorization system is implemented by userspace.

The all-powerful root and suid binaries that so many people deride (whether justly or otherswise) are necessary for effective separations. It is possible to completely swap out the authentication mechanism while leaving the security intact (ssh does this, which is why it uses undocumented APIs on Windows).

---

Difference between mechanism and policy mechanism determines how to do something, policies decide what will be done.

The separation of policy from mechanism is very important principle, it allows maximum flexibility if policy decisions are to be changed later.

---

Although this is a very old question, I still want to share my point.

The reason why this passage is confusing is because of the two words "mechanism" and "policy". And in the context of software engineering, I think it's always ok to replace "mechanism" with "interface" and "policy" with "implementation".

As for the separation of interface and implementation, if you're programming in Java, then you must be quite familiar with these two concepts. By doing so, we can isolate "what to do" from "how to do", which helps us achieve system decoupling.

Why decoupling? Decoupling improves the extensibility and maintainability of the code, which means we can write less code when requirements change :)

Learn more techniques about decoupling from "The GoF Design Patterns".