深入理解編程藝術之策略與機制相分離
[導讀]在現(xiàn)代操作系統(tǒng)的結構設計中，經常利用“機制與策略分離”的原理來構造OS結構。
在現(xiàn)代操作系統(tǒng)的結構設計中，經常利用“機制與策略分離”的原理來構造OS結構。所謂機制，是指實現(xiàn)某一功能的具體執(zhí)行機構。而策略，則是在機制基礎上，借助于某些參數(shù)和算法來實現(xiàn)該功能的優(yōu)化，或達到不同的功能目標。通常，機制處于一個系統(tǒng)的基層，而策略則處于系統(tǒng)的高層。
在程序設計中，機制與策略分離的思想可以提高程序的可復用性，可維護性和可調試性使程序更具有高內聚低耦合性。如果說機制是磚，那么策略就是房子，同樣的磚可以建不同的房子，我們不能把建磚和建房子混在一起實現(xiàn)。策略的變化要遠遠大于機制的變化。將兩者分離，可以使機制相對保持穩(wěn)定，而同時支持策略的變化。
在代碼大全中提到“隔離變化”的概念，以及設計模式中提到的將易變化的部分和不易變化的部分分離也是這個思路。
在《Unix編程藝術》第一章就深刻討論這個編程哲學：
“在我們對 Unix 錯誤的討論中，我們觀察到 X window的設計者做出了一個基本決定來實現(xiàn)“機制，而不是策略” —— 使 X 成為一個通用的圖形引擎，并將有關用戶界面風格的決定留給工具包和其他級別的系統(tǒng)。我們通過指出政策和機制傾向于在不同的時間尺度上發(fā)生變異來證明這一點，政策的變化比機制快得多，GUI 工具包的外觀和感覺上的時尚可能來來去去，但光柵操作和合成是永恒的。
因此，將策略和機制硬連接在一起會產生兩個負面影響：它使策略變得僵化并且更難以響應用戶需求而改變，這意味著試圖改變策略有很強的破壞機制穩(wěn)定的傾向。
另一方面，通過將兩者分開，我們可以在不破壞機制的情況下試驗新策略。我們還使為機制編寫好的測試變得更加容易。
實現(xiàn)這種分離的一種方法是，例如，將應用程序編寫為由嵌入式腳本語言驅動的 C服務例程庫，應用程序控制流是用腳本語言而不是 C 編寫的。這種模式是Emacs編輯器，它使用嵌入式 Lisp解釋器來控制用 C 編寫的編輯原語。
另一種方法是將您的應用程序分成協(xié)作的前端和后端進程，這些進程通過套接字上的專用應用程序協(xié)議進行通信；前端執(zhí)行策略，后端實現(xiàn)機制。這樣的全局復雜性通常遠低于實現(xiàn)相同功能的單進程單體的復雜性，從而減少您對錯誤的脆弱性并降低生命周期成本（提高健壯性）?！?/span>
一些例子
GUI框架MVC(Model-View-Controller)作為最經典的GUI架構，MVC模式的核心思想是數(shù)據(jù)層(Domain)與表現(xiàn)層(Presentation)的隔離。
- 模型（Model） 用于封裝與應用程序的業(yè)務邏輯相關的數(shù)據(jù)以及對數(shù)據(jù)的處理方法?！?Model ”有對數(shù)據(jù)直接訪問的權力，例如對數(shù)據(jù)庫的訪問?！癕odel”不依賴“View”和“Controller”，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中數(shù)據(jù)的變化一般會通過一種刷新機制被公布。為了實現(xiàn)這種機制，那些用于監(jiān)視此 Model 的 View 必須事先在此 Model 上注冊，從而，View 可以了解在數(shù)據(jù) Model 上發(fā)生的改變。
- 視圖（View）能夠實現(xiàn)數(shù)據(jù)有目的的顯示（理論上，這不是必需的）。在 View 中一般沒有程序上的邏輯。為了實現(xiàn) View 上的刷新功能，View 需要訪問它監(jiān)視的數(shù)據(jù)模型（Model），因此應該事先在被它監(jiān)視的數(shù)據(jù)那里注冊。
- 控制器（Controller）起到不同層面間的組織作用，用于控制應用程序的流程。它處理事件并作出響應?！笆录卑ㄓ脩舻男袨楹蛿?shù)據(jù) Model 上的改變。
netfilter框架
netfilter框架是一個典型將機制和策略分離好例子：
Netfilter是一個設計良好的框架，之所以說它是一個框架是因為它提供了最基本的底層支撐，而對于實現(xiàn)的關注度卻沒有那么高，這種底層支撐實際上是5個HOOK點：
PREROUTING：數(shù)據(jù)包進入網絡層路由前FORWARD：數(shù)據(jù)包路由之后確定要轉發(fā)之后INPUT：數(shù)據(jù)包路由之后確定要本地接收之后OUTPUT：本地數(shù)據(jù)包發(fā)送POSTROUTING：數(shù)據(jù)包發(fā)出去之前
Netfilter擁有幾乎無限的可擴展性， Liuux中使用的僅僅是它的一個很小的部分，大部分的內容作為可插拔的module處于待命狀態(tài)Netfilter的機制集成在Linux內核中， 然而它的策略擴展卻處于一個獨立的空間，我們說這種所謂的機制也僅僅是5個HOOK點。我們?yōu)g覽netfilter.org就會知道，它里面融合了大量的策略，我們最熟悉的就是iptables了，上圖的ebtables，arptables，nft也是Netfilter的擴展之一， 足以看出，Netfilter有多強大，內核僅僅給出鉤子點而已， 如果你嫌某些不好，你可以自己實現(xiàn)一個更好的，事實上，Netfilter中有很多的東西并沒有集成在Linux內核。
TCP擁塞控制框架
Linux系統(tǒng)中的TCP擁塞控制采用面向對象的設計思想，提供擁塞控制接口用于實現(xiàn)不同的擁塞控制策略，成功把擁塞控制解耦了：
eBPF框架
-
內核實現(xiàn)BPF虛擬機執(zhí)行核心引擎，屬于機制部分；
- 用戶態(tài)可以編寫各種BPF程序，實現(xiàn)不同策略功能；
游戲引擎
游戲引擎架構
游戲引擎便是專門為游戲而設計的工具及技術集成，之所以稱為引擎，如同交通工具中的引擎，提供了最核心的技術部分--游戲機制，然后可以通過腳本語言或者關卡設計來插入策略邏輯，重用性是游戲引擎的一個重要設計目標，這樣很多游戲開發(fā)都可以通過"換皮策略"來快速開發(fā)新游戲。
最后一些問題
1、透過現(xiàn)象看本質，機制與策略到底是什么？為什么要將機制與策略分離？機制可以認為是業(yè)務通用的核心模型（框架），不易變化；策略可以認為是某個功能的具體實現(xiàn)方案，可以被框架使用；機制與策略分離，是一種可擴展性設計的重要方法，提供一個繼承接口，用于提供不同的實現(xiàn)，這也就是策略模式和接口隔離原則。機制關聯(lián)一個抽象的策略（也就是接口），用不同的具體策略初始化抽象策略，就能調用具體策略的處理流程。
2、假如不分離，會出現(xiàn)什么問題？
把策略同機制揉成一團有兩個負面影響：一來會使策略變得死板，難以適應用戶需求的改變，二來也意味著任何策略的改變都極有可能動搖機制，對原來穩(wěn)定的框架造成污染，引入風險。
所以我們在設計系統(tǒng)的時候，可以參考這種機制和策略模式，讓系統(tǒng)具有更好的擴展性和更好的穩(wěn)定性。
下載文檔
