政策与机制
我在阅读操作系统教科书时遇到了“分离机制和策略”的概念。我不确定这意味着什么，所以我查看了维基百科，我必须承认，这也没有多大帮助。
机制与机制分离 策略[1]是一个设计原则 计算机科学。它指出 机制（系统的那些部分 控制的实现 操作授权和 资源分配）不应该 规定（或过度限制） 决策所依据的政策 进行了哪些操作 授权哪些资源 分配。
有人可以缓和一下这个问题吗？如果可能的话，用几个例子来解释一下在操作系统的背景下机制和策略的分离意味着什么？
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 tone this down, and explain if possible with a few examples what separation of mechanism and policy means in the context of Operating systems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这对于 X-Windows 系统意味着什么。
X-Windows 在底层提供了一种称为“窗口”的操作屏幕区域的方法。它还提供了一种接收窗口内发生的事件的方法。
但是 X-Windows 没有提及标题栏、菜单、滚动条或任何类似的东西。它还没有说明特定应用程序可以使其窗口占据整个屏幕的规则，或者何时必须将窗口移出屏幕的规则。它确实为一个应用程序提供了一种方法，可以强制其他应用程序在使用顶级窗口执行操作之前请求其许可，但不提供任何此类应用程序作为基础服务器的一部分。
X-Windows 完全是关于机制，而不是策略。
该策略由小部件工具包、窗口管理器以及稍后添加到系统的其他东西提供。例如，许多小部件工具包使用一组重叠的子窗口作为滚动条，并向这些子窗口请求鼠标事件，以便它们可以检测单击和拖动操作并使子窗口做出适当的响应。
这就是为什么 GNOME 和 KDE 可以在同一显示器上运行，以及为什么对面板或桌面一无所知的真正古老的 X-Windows 程序仍然可以在现代系统上正常运行。
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.
对于*nix操作系统，总体思路是安全系统由内核实现，授权系统由用户空间实现。
许多人（无论公正与否）嘲笑的全能 root 和 suid 二进制文件对于有效分离是必要的。可以完全替换身份验证机制，同时保持安全性不变（ssh 就是这样做的，这就是它在 Windows 上使用未记录的 API 的原因）。
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).
虽然这是一个很老的问题，但我仍然想分享我的观点。
这段话之所以让人困惑，是因为“机制”和“政策”这两个词。在软件工程的背景下，我认为用“接口”代替“机制”，用“实现”代替“策略”总是可以的。
至于接口和实现的分离，如果你用Java编程，那么你一定对这两个概念非常熟悉。这样做，我们可以将“做什么”和“怎么做”隔离开来，从而帮助我们实现系统解耦。
为什么要解耦？解耦提高了代码的可扩展性和可维护性，这意味着当需求发生变化时我们可以编写更少的代码:)
从《The GoF Design Patterns》中了解更多关于解耦的技术。
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".
机制与政策的区别
机制决定怎么做，政策决定做什么。
政策与机制的分离是非常重要的原则，如果以后要改变政策决策，它可以提供最大的灵活性。
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.