首先說，接口是一個定義極多的詞匯，每一本書使用接口這個詞的時候都有不同的語境，代表不同的意思。
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，寫太多了，累了。