首先说，接口是一个定义极多的词汇，每一本书使用接口这个词的时候都有不同的语境，代表不同的意思。
1，类的一个public方法/函。
2，一个只拥有纯虚函数的类，一般用interface定义。
3，程序操作界面。
在《UNIX编程艺术》一书中，接口是“程序同人类用户以及其他程序通讯方法的总和”。通俗的说，接口是程序获得输入数据和命令的来源。具体有这些情形，程序的执行参数，或者基于IPC的一套应用协议/数据格式，或者是人类使用的CLI或者GUI所有效的操作。与此相应的是，程序的实际功能被称为接口功能。不能很好的理解该书对接口的定义，便不能很好的阅读这一章。

对接口的优劣评价有5项指标，不过归结只是3个词而已：简单，直观，脚本化。
脚本化是UNIX文化中最重要的东西了吧，在整本书中一直可以看到相关的概念，这种组件的表达方式比起链接库之类的具有更大的独立性，即使出错也不会轻易的crash主进程。

不说废话了。下面简单列举并评述一下这一章所描述的接口模式。

1，过滤器模式。从stdin接受数据，转换成另一种格式后输出到stdout。需要注意的是，这里是指接受数据，而非命令。该模式具有“单向流”的特点，完全是为脚本化而存在的。
我近段时间曾使用过几次这种模式，不过不是为了脚本化，而仅仅是为了转换格式。我所参与的project中，有些看起来很重复的代码需要重构，比较符合自动化的条件，于是书写了过滤器，协助重构工作。
实际的经验中要考虑的是，过滤器的过滤粒度问题，也就是吸收多大一捆数据后，才执行一次格式转换（可以称为batch）。根据实际问题的条件，batch的大小有可能是一行，也有可能是几行，也有可能是所有的数据都到达后才能执行，不过这种情形比较少见。
使用过滤器还有些潜规则是：
宽进严出，想必第一次看到这4个字的时候都以为是要限制输出内容的意思，我也是这样。不过实际上并不是指内容，而是指格式。能最大程度容忍格式不太规范的输入，而自身对输出格式要良好定义，并按这种格式输出，以便方便下一个程序解析使用。
过滤时，不要丢弃不需要的信息。这个信息是指从stdin读取的数据。我觉得，这个不能丢弃的信息的粒度是以batch为单位的。某个batch没有过滤处理，就直接发送到stdout；如果只是batch中的某一行数据没有过滤处理，实际上整个batch已经利用过了，而还要把那行数据保留输出，只会引起下游程序的困惑。
过滤时，决不增加无用数据。沉默的法则，待会说。

2，接下来一口气说3个模式，是因为这些模式或多或少是过滤器的近亲，缺胳膊少腿的，又没有自己的特色，就能有自己的一个模式名，什么世道啊。
cantrip,没输入没输出，只能通过启动命令行指定运行；
源模式，没输入，但有输出；
接收器模式，有输入，但没输出；
看完以上，你觉得无聊吧，这3个东西也能有自己的名字···3者有脚本化能力。

3，编译器模式···在启动命令行中指定输入数据文件和输出数据文件，没有stdin和stdout。编译器模式和过滤器模式几乎做同样的工作，但是为什么编译器模式不使用标准输入输出呢？UNIX没有把标准输入输出重定向到文件的能力吗？事实上，在windows下，把过滤器模式变成编译器的样子，大概只需要重定向一下，例如：filter.exe  <  input.txt  > output.txt。

4，ed模式。第一次看到ed模式，简直毫不理解为什么过滤器模式要跑到这来换一个名字继续骗人。回到刚才聊过滤器模式提到要注意的地方，没错了，两者虽然很像，但有两个区别：
ed模式接受的是命令，而不是数据。每行一个命令，回车后会执行该命令所代表的功能，同时可能会变迁程序的状态。
ed模式需要维护会话状态。过滤器一次性的接受输入数据，一次性的处理，一次性的输出数据，在会话尺度上可以说是瞬间的。但是ed模式一次接受一条命令，执行后输出执行结果，同时程序状态可能会迁移。
ed模式也可以脚本化的，只是调用程序很可能要确认使用该模式程序的状态，并且脚本中的命令也要遵循这种状态才可以。
不过话说回来，ed模式是我们windows用户学习编程最先用到的程序了。回忆一下曾经写过的东西，都是输入回车，然后得到某种执行。呵。

5，Roguelike模式。字符阵列GUI（如果这也可以称为GUI的话），通过单键出发（像游戏手柄一样），废弃。

6，接口和引擎分离模式。引擎是指应用程序专用定义域的数据结构和逻辑，比喻为工作者进程也许会更贴切大家；接口负责接受用户命令，并显示结果，GUI的或者CLI的。
C/S模式是大家最熟悉的接口和引擎分离模式了。不过本章对此的划分可是比较细致，我看区却只是引擎部分的接口模式不同而已，接口部分还是一样的。以下模式名称都约定前者为接口，后者为引擎。
配置者/执行者模式。白话的说就是配置者负责配置执行者的执行行为，引擎一般使用类似于cantrip这种无需接口关心其输出的模式，并且需要接口主动调用。
假脱机/守护进程组合。脱机程序和守护者进程有一个约定的地方，脱机程序就是往那个地方扔东西，而守护者进程就是只打扫那个地方的东西。甚至可以说，接口和引擎完全不需要认识对方，也就不必关心对方的状态，反正把东西扔那里就没错了。
驱动/引擎组合；C/S组合。把两个合起来说，因为我觉得他们是一样的。同时由于大家对于C/S的熟悉程度，也无需多说。重要的问题就在设计引擎所接受的命令和返回的状态的语法上，这可以称为应用协议或者微型语言。接口需要向引擎发送命令，并获得引擎的状态，以便返回给用户。
综上所述，接口/引擎分离模式，接口只需要关心协议，而协议指定的工作怎么完成，就无所谓了。

7，CLI服务器模式。不知道这样一种模式是什么意思···它要说明的只是，服务器使用标准输入输出，然后由一个守护程序，把这些输入输出连接到套接字上。这，就像是对引擎程序的拆分，服务器使用标准输入输出，可以很方便的在缺乏接口/客户端程序的情况进行本地测试与调试，等接口/客户端弄好之后，给服务器一个守护进程，守护进程启动服务器，把服务器的输入输出都连接到套接字上，系统就搭建起来了。此外，守护进程一般有做安全门卫的能力。
与其说这是一个模式，倒不如说是解决C/S模式调试的好方法。

8，感谢上帝，终于到多价程序模式了，这种模式在windows下相当的普遍。也就是，程序的应用逻辑被封存在一个API库中，可以被欲使用其功能的程序编译链接。

9，策略/机制模式。不知道这是不是接口模式，本章没有多说，但是在别的章节中老说到这个短语。
策略/机制模式，其核心是可配置性，可配置一切一切跟外观有关的东西，从每一根头发到每一滴血，从身体到灵魂（局外人：“那是解放者之契约”。偶：“实现汝的愿望”）。
无论是X，还是CEGUI，或者windows，其界面都可以配置。机制是工作的核心逻辑，而策略是一个具体的配置。
说CEGUI，有XXXLook这样的东西，不同的xxxLook，所看到的是不一样的东西，但是代码本身并没有变。
又如Windows，各种主题，Mac的，番茄花园的，都是一些指定了配置的文本行主题文件，而Windows下的显示机制，并不需要改变。

10，写太多了，累了。