《Unix 编程艺术》 理解

一：机制， 而不是策略

Unix文化贯穿始终的一条设计主线， 被翻译为： 机制， 而不是策略(Mechanism, not policy), 这句话的英文解释如下：

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.

翻译过来：机制和策略的区别， Unix设计中最棒的思想之一， 大多程序的问题， 可以分离为两个问题： 提供什么样的功能(即机制)； 这些功能是怎么使用的(策略)。 如果在一个程序中的各个模块，甚至是不同程序间，突出强调这两个问题， 那么， 程序包将更容易开发并被特定的应用所采纳。

由此看来， Unix的设计偏重于程序提供什么样的功能， 并不注重程序是如何被用到的。 所谓提供什么样的功能，不仅仅指为User提供这样功能，还包括对其它模块或者其它程序提供这样的功能。 因此Unix注重功能设计，注重接口，但并不在乎这个功能会如何用到。所以，你用命令行，还是用GUI去调用， Unix设计者是不关心这个的。 他们在乎的是： OK， 我已经实现了这个功能了。

为什么用户觉得Unix不好用呢！ Unix程序员给你的答案是： 我不关心这个， 功能我已经实现了，并且，我跟其它模块和程序的接口完全解耦，API接口都是文本或者数据流，或者是协议。 我觉得事情已经OK了。

对于还是小白的用户来说，这样几乎是灭顶之灾，他很快就迷失，然后崩溃，最后出离愤怒， 这是显然的。

但对于程序员而言， 设想一下， 通过软件查询了一个结果，把它显示成在GUI上，渐变，渲染，若隐若现，跟我直观的打到shell上，区别在哪里?

程序员更应该关注机制，关注和外界的接口。 这就是为什么《Unix 编程艺术》 受到那么多程序员的追捧，无论是Linux用户还是windows，无论是C-Programer还是Java-Coder。 因为它关注的重点是架构。

《Unix编程艺术》中也给作者的理解： 因为策略和机制是按照不同的时间尺度变化的， 策略的变化要源源快于机制。 GUI工具包的观感时尚来去匆匆， 而光栅操作和组合确是永恒的。 这点跟设计模式的基本原则“分离可变和不变部分” 有着异曲同工， 只不过将其更加细化成“变化快和变化慢”的部分。

待续