首先說，接口是一個定義極多的詞匯，每一本書使用接口這個詞的時候都有不同的語境，代表不同的意思。
1，類的一個public方法/函。
2，一個只擁有純虛函數(shù)的類，一般用interface定義。
3，程序操作界面。
在《UNIX編程藝術(shù)》一書中，接口是“程序同人類用戶以及其他程序通訊方法的總和”。通俗的說，接口是程序獲得輸入數(shù)據(jù)和命令的來源。具體有這些情形，程序的執(zhí)行參數(shù)，或者基于IPC的一套應(yīng)用協(xié)議/數(shù)據(jù)格式，或者是人類使用的CLI或者GUI所有效的操作。與此相應(yīng)的是，程序的實際功能被稱為接口功能。不能很好的理解該書對接口的定義，便不能很好的閱讀這一章。

對接口的優(yōu)劣評價有5項指標(biāo)，不過歸結(jié)只是3個詞而已：簡單，直觀，腳本化。
腳本化是UNIX文化中最重要的東西了吧，在整本書中一直可以看到相關(guān)的概念，這種組件的表達方式比起鏈接庫之類的具有更大的獨立性，即使出錯也不會輕易的crash主進程。

不說廢話了。下面簡單列舉并評述一下這一章所描述的接口模式。

1，過濾器模式。從stdin接受數(shù)據(jù)，轉(zhuǎn)換成另一種格式后輸出到stdout。需要注意的是，這里是指接受數(shù)據(jù)，而非命令。該模式具有“單向流”的特點，完全是為腳本化而存在的。
我近段時間曾使用過幾次這種模式，不過不是為了腳本化，而僅僅是為了轉(zhuǎn)換格式。我所參與的project中，有些看起來很重復(fù)的代碼需要重構(gòu)，比較符合自動化的條件，于是書寫了過濾器，協(xié)助重構(gòu)工作。
實際的經(jīng)驗中要考慮的是，過濾器的過濾粒度問題，也就是吸收多大一捆數(shù)據(jù)后，才執(zhí)行一次格式轉(zhuǎn)換（可以稱為batch）。根據(jù)實際問題的條件，batch的大小有可能是一行，也有可能是幾行，也有可能是所有的數(shù)據(jù)都到達后才能執(zhí)行，不過這種情形比較少見。
使用過濾器還有些潛規(guī)則是：
寬進嚴(yán)出，想必第一次看到這4個字的時候都以為是要限制輸出內(nèi)容的意思，我也是這樣。不過實際上并不是指內(nèi)容，而是指格式。能最大程度容忍格式不太規(guī)范的輸入，而自身對輸出格式要良好定義，并按這種格式輸出，以便方便下一個程序解析使用。
過濾時，不要丟棄不需要的信息。這個信息是指從stdin讀取的數(shù)據(jù)。我覺得，這個不能丟棄的信息的粒度是以batch為單位的。某個batch沒有過濾處理，就直接發(fā)送到stdout；如果只是batch中的某一行數(shù)據(jù)沒有過濾處理，實際上整個batch已經(jīng)利用過了，而還要把那行數(shù)據(jù)保留輸出，只會引起下游程序的困惑。
過濾時，決不增加無用數(shù)據(jù)。沉默的法則，待會說。

2，接下來一口氣說3個模式，是因為這些模式或多或少是過濾器的近親，缺胳膊少腿的，又沒有自己的特色，就能有自己的一個模式名，什么世道啊。
cantrip,沒輸入沒輸出，只能通過啟動命令行指定運行；
源模式，沒輸入，但有輸出；
接收器模式，有輸入，但沒輸出；
看完以上，你覺得無聊吧，這3個東西也能有自己的名字···3者有腳本化能力。

3，編譯器模式···在啟動命令行中指定輸入數(shù)據(jù)文件和輸出數(shù)據(jù)文件，沒有stdin和stdout。編譯器模式和過濾器模式幾乎做同樣的工作，但是為什么編譯器模式不使用標(biāo)準(zhǔn)輸入輸出呢？UNIX沒有把標(biāo)準(zhǔn)輸入輸出重定向到文件的能力嗎？事實上，在windows下，把過濾器模式變成編譯器的樣子，大概只需要重定向一下，例如：filter.exe? <? input.txt? > output.txt。

4，ed模式。第一次看到ed模式，簡直毫不理解為什么過濾器模式要跑到這來換一個名字繼續(xù)騙人。回到剛才聊過濾器模式提到要注意的地方，沒錯了，兩者雖然很像，但有兩個區(qū)別：
ed模式接受的是命令，而不是數(shù)據(jù)。每行一個命令，回車后會執(zhí)行該命令所代表的功能，同時可能會變遷程序的狀態(tài)。
ed模式需要維護會話狀態(tài)。過濾器一次性的接受輸入數(shù)據(jù)，一次性的處理，一次性的輸出數(shù)據(jù)，在會話尺度上可以說是瞬間的。但是ed模式一次接受一條命令，執(zhí)行后輸出執(zhí)行結(jié)果，同時程序狀態(tài)可能會遷移。
ed模式也可以腳本化的，只是調(diào)用程序很可能要確認使用該模式程序的狀態(tài)，并且腳本中的命令也要遵循這種狀態(tài)才可以。
不過話說回來，ed模式是我們windows用戶學(xué)習(xí)編程最先用到的程序了。回憶一下曾經(jīng)寫過的東西，都是輸入回車，然后得到某種執(zhí)行。呵。

5，Roguelike模式。字符陣列GUI（如果這也可以稱為GUI的話），通過單鍵出發(fā)（像游戲手柄一樣），廢棄。

6，接口和引擎分離模式。引擎是指應(yīng)用程序?qū)Ｓ枚x域的數(shù)據(jù)結(jié)構(gòu)和邏輯，比喻為工作者進程也許會更貼切大家；接口負責(zé)接受用戶命令，并顯示結(jié)果，GUI的或者CLI的。
C/S模式是大家最熟悉的接口和引擎分離模式了。不過本章對此的劃分可是比較細致，我看區(qū)卻只是引擎部分的接口模式不同而已，接口部分還是一樣的。以下模式名稱都約定前者為接口，后者為引擎。
配置者/執(zhí)行者模式。白話的說就是配置者負責(zé)配置執(zhí)行者的執(zhí)行行為，引擎一般使用類似于cantrip這種無需接口關(guān)心其輸出的模式，并且需要接口主動調(diào)用。
假脫機/守護進程組合。脫機程序和守護者進程有一個約定的地方，脫機程序就是往那個地方扔?xùn)|西，而守護者進程就是只打掃那個地方的東西。甚至可以說，接口和引擎完全不需要認識對方，也就不必關(guān)心對方的狀態(tài)，反正把東西扔那里就沒錯了。
驅(qū)動/引擎組合；C/S組合。把兩個合起來說，因為我覺得他們是一樣的。同時由于大家對于C/S的熟悉程度，也無需多說。重要的問題就在設(shè)計引擎所接受的命令和返回的狀態(tài)的語法上，這可以稱為應(yīng)用協(xié)議或者微型語言。接口需要向引擎發(fā)送命令，并獲得引擎的狀態(tài)，以便返回給用戶。
綜上所述，接口/引擎分離模式，接口只需要關(guān)心協(xié)議，而協(xié)議指定的工作怎么完成，就無所謂了。

7，CLI服務(wù)器模式。不知道這樣一種模式是什么意思···它要說明的只是，服務(wù)器使用標(biāo)準(zhǔn)輸入輸出，然后由一個守護程序，把這些輸入輸出連接到套接字上。這，就像是對引擎程序的拆分，服務(wù)器使用標(biāo)準(zhǔn)輸入輸出，可以很方便的在缺乏接口/客戶端程序的情況進行本地測試與調(diào)試，等接口/客戶端弄好之后，給服務(wù)器一個守護進程，守護進程啟動服務(wù)器，把服務(wù)器的輸入輸出都連接到套接字上，系統(tǒng)就搭建起來了。此外，守護進程一般有做安全門衛(wèi)的能力。
與其說這是一個模式，倒不如說是解決C/S模式調(diào)試的好方法。

8，感謝上帝，終于到多價程序模式了，這種模式在windows下相當(dāng)?shù)钠毡椤Ｒ簿褪牵绦虻膽?yīng)用邏輯被封存在一個API庫中，可以被欲使用其功能的程序編譯鏈接。

9，策略/機制模式。不知道這是不是接口模式，本章沒有多說，但是在別的章節(jié)中老說到這個短語。
策略/機制模式，其核心是可配置性，可配置一切一切跟外觀有關(guān)的東西，從每一根頭發(fā)到每一滴血，從身體到靈魂（局外人：“那是解放者之契約”。偶：“實現(xiàn)汝的愿望”）。
無論是X，還是CEGUI，或者windows，其界面都可以配置。機制是工作的核心邏輯，而策略是一個具體的配置。
說CEGUI，有XXXLook這樣的東西，不同的xxxLook，所看到的是不一樣的東西，但是代碼本身并沒有變。
又如Windows，各種主題，Mac的，番茄花園的，都是一些指定了配置的文本行主題文件，而Windows下的顯示機制，并不需要改變。

10，寫太多了，累了。