提供什么能力"(机制) 和 "如何使用这些能力"(策略) 此话怎么解

[星土]

我的问题：我们做某个东西，确实可以划分为俩个部分，这个东西有什么用，这个东西是怎么做的，该怎么用。

 提供什么能力"(机制) 和 "如何使用这些能力"(策略)

在我意识里  机制跟策略是近义词，这样形容，我就不理解了。

机制和策略的区分是其中一个在 Unix 设计背后的最好观念. 大部分的编程问题其实可以

划分为 2 部分:" 提供什么能力"(机制) 和 "如何使用这些能力"(策略). 如果这两方面

由程序的不同部分来表达, 或者甚至由不同的程序共同表达, 软件包是非常容易开发和适

应特殊的需求. 

例如, 图形显示的 Unix 管理划分为 X 服务器, 它理解硬件以及提供了统一的接口给用

户程序, 还有窗口和会话管理器, 它实现了一个特别的策略, 而对硬件一无所知. 人们可

以在不同的硬件上使用相同的窗口管理器, 而且不同的用户可以在同一台工作站上运行不

同的配置. 甚至完全不同的桌面环境, 例如 KDE 和 GNOME, 可以在同一系统中共存. 另

一个例子是 TCP/IP 网络的分层结构: 操作系统提供 socket 抽象层, 它对要传送的数据

• 以下是原文

The distinction between mechanism and policy is one of the best ideas behind the

Unix design. Most programming problems can indeed be split into two parts: “what

capabilities are to be provided” (the mechanism) and “how those capabilities can be

used” (the policy). If the two issues are addressed by different parts of the program,

or  even  by  different  programs  altogether,  the  software  package  is  much  easier  to

develop and to adapt to particular needs.

For example, Unix management of the graphic display is split between the X server,

which knows the hardware and offers a unified interface to user programs, and the

window and session managers, which implement a particular policy without know-

ing anything about the hardware. People can use the same window manager on dif-

ferent hardware, and different users can run different configurations on the same

workstation.  Even  completely  different  desktop  environments,  such  as  KDE  and

GNOME, can coexist on the same system. Another example is the layered structure

of  TCP/IP  networking:  the  operating  system  offers  the  socket  abstraction,  which

implements no policy regarding the data to be transferred, while different servers are

in charge of the services (and their associated policies). Moreover, a server like ftpd

provides the file transfer mechanism, while users can use whatever client they prefer;

both command-line and graphic clients exist, and anyone can write a new user inter-

face to transfer files.

[Li Jie]

我说个例子, 我觉得挺能反映机制和策略的问题.

Apache Zookeeper, 以前是hadoop的一个子项目. 它提供一种类似文件系统的API:

Create/Read/Delete文件和目录, 以及Watch来监听文件或目录的改变. 这就是它的基本能力.

但zookeeper在具体的系统中能够承担
分布式锁, 分布式读写锁, 消息通知, 2PhaseCommit等等非常复杂的一些任务

这种利用基本能力的组合, 来处理一些非常复杂的应用的做法,
典型反映了: 提供能力(机制)和如何使用(策略)

[Neo Sun]

我也举个例子，不知道对不对。
硬件led灯。
驱动提供机制，点亮led灯，关闭led灯。
策略可以选择怎么亮，显示成什么样子。

发自我的 iPhone

[Stanley Peng]

是的，在LDD中，机制就是驱动，提供最基本功能，比如声音，视频驱动，策略就是应用，比如音视频播放器，用具体的方式播放特定的文件。

[Risingv]

机制就是提供了抽象层的答案，它提供的是对一类问题的基本观点和基本方法。

而策略就是建立于机制提供的基本的element，通过不同的排列组合来解决特定的问题。

所以建立好的机制，可以减小解决问题的成本，灵活应对。

其实任何编程语言都可以是最最常见的例子，它们本身并不解决任何实际问题，但是通过对控制结构、分支结构、变量、函数封装的灵活组合和应用， 你可以解决各种各样的问题。

Unix最典型的例子应该是Shell，ls grep cat 各个命令专注于最细粒度和同时最具有实际意义的小问题的答案，通过管道、重定向和shell语法，只是一个简单脚本的代价就可以解决看似很复杂的问题，而且可以随时可以狠灵活地修改。而在windows下，代价往往是重新实现一个软件。

--
Life is in chaos, keep struggling.

Personal blog: risingv.in

[星土]

这俩个单词，我的意识里，我把这俩个单词当近义词，机制等于策略，感觉都是方法。课本上好像就是这么学的。

[星土]

http://www.zeuux.com/blog/content/1729/   

这个词不是一本书上出现，unix接口技术也提到

陈莉君  2009年10月21日 星期三 08:48 | 1396次浏览 | 21条评论

Unix/Linux的接口设计有一句通用的格言“提供机制而不是策略”。区别对待机制（mechanism）和策略（policy）是Unix设计中的一大亮点。大部分的编程问题都可以被切割成两个部分：“需要提供什么功能”（机制）和“怎样实现这些功能”（策略）。如果由程序中的独立部分分别负责机制和策略的实现，那么开发软件就更容易，也更容易适应不同的需求。

Unix/Linux 的接口设计有一句通用的格言“提供机制而不是策略”。    区别对待机（mechanism）和策略（policy）是Unix设计中的一大亮点。大部分的编程问题都可以被切割成两个部分：“需要提供什么功能”（机制）和“怎样实现这些功能”（策略）。如果由程序中的独立部分分别负责机制和策略的实现，那么开发软件就更容易，也更容易适应不同的需求。

   开源 - 展现在我们面前的是数以千计的代码，在那一行行的代码背后，到底蕴藏着怎样的设计思想，高手们曾怎样苦思冥想。在一堆堆的代码面前，有时候，我们很容易迷失曾经进来的入口，而掉入符号，变量以及函数堆积成的沼泽地。

  操作系统的本质是什么？管理者？亦或服务者？但，归根结底，它是一个执行者：执行用户程序 - 所谓为用户服务；执行中断- 所谓为外设服务；执行系统调用 - 所谓解放程序员（姑且说它为广大的程序员服务，因为程序员不再与繁杂的硬件打交道了）；执行内核线程-为操作系统自身服务。而这所有执行的核心，无非是在恰当的时机，让哪个对象（程序，线程，中断服务程序，中断的下半部，系统调用）占有CPU 。换句话说， Unix/Linux 抽象出对这些对象的执行机制: 

•   程序的执行机制 - 进程
•   内核函数的执行机制 - 线程
•   中断服务程序的执行机制 - 中断信号触发
•   中断下半部的执行机制 -softirq ， tasklet ，工作队列
•   系统调用的执行 - 软中断（ int $0x80 触发）

  

  从机制和策略的角度看问题，也许，你对曾经困惑的问题有赫然开朗之感。

  如果说机制是一种框架，那么，策略就是填充框架的一个个具体实体。机制提供的是一种开放而宽松的环境，而策略就是在这个环境下赖以生存的生命个体。比如，我们编写的一个程序，fork()以后，就成为一个个进程的生命个体。而操作系统所提供给我们创建、执行以及结束进程的各种原语-fork(),exex()和exit（）等是统管各种进程的机制。我们所创建进程的死活并不会影响机制本身。

 如此看来，也许我们对原理之困惑有所醒悟。我们任何人在任何时候都可以调用fork()创建N多进程。这样一个简单的fork（）壳，想追根溯源者，剥开这个壳，可以看到其五脏六腑。fork()如果出现任何一个小bug，直接影响到我们任何人和任何进程。

如此看来，也许我们对开发者所承担的角色有所感悟。系统分析员和设计人员，任重而探究的路漫漫兮。说到此，设计模式等系列书，对有志于从编码走向设计的开发者或许有所启发。

在 2013年1月14日星期一UTC+8下午6时55分24秒，星土写道：

[Risingv]

unix接口技术也提到? 机制和策略分离的思想本来就源自于Unix哲学

学过《现代操作系统》的，基本都知道这个思想

本质上解决的就是问题是为了重用和便于拓展，降低解决问题的成本

看看1984年设计的 X window 为什么能使用至今，就是这个原因。