1.6.4 分離原則: 策略同機制分離，介面同引擎分離

在Unix之失的討論中，我們談到過X系統的設計者在設計中的基本抉擇是實行“機制，而不是策略”這種做法——使X成為一個通用圖形引擎，而將使用者介面風格留給工具包或者系統的其它層次來決定。這一點得以證明是正確的，因為策略和機制是按照不同的時間尺度變化的，策略的變化要遠遠快於機制。GUI工具包的觀感時尚來去匆匆，而光柵操作和組合卻是永恆的。

所以，把策略同機制揉成一團有兩個負面影響：一來會使策略變得死板，難以適應使用者需求的改變，二來也意味著任何策略的改變都極有可能動搖機制。

相反，將兩者剝離，就有可能在探索新策略的時候不足以打破機制。另外，我們也可以更容易為機制寫出較好的測試（因為策略太短命，不值得花太多精力在這上面）。

這條設計準則在GUI環境之外也被廣泛應用。總而言之，這條準則告訴我們應該設法將介面和引擎剝離開來。

實現這種剝離的一個方法是，比如，將應用按照一個庫來編寫，這個庫包含許多由內嵌指令碼語言驅動的C服務程式，而至於整個應用的控制流程則用指令碼來撰寫而不是用C語言。這種模式的經典例子就是Emacs編輯器，它使用內嵌的指令碼語言Lisp直譯器來控制用C編寫的編輯原語操作。我們會在第11章討論這種設計風格。

另一個方法是將應用程式分成可以協作的前端和後端程式，通過套接字上層的專用應用協議進行通訊；我們會在第5章和第7章討論這種設計。前端實現策略，後端實現機制。比起僅用單個程式的整體實現方式來說，這種雙端設計方式大大降低了整體複雜度，bug有望減少，從而降低程式的壽命週期成本。