在現代操作系統的結構設計中，經常利用“機制與策略分離”的原理來構造OS結構。所謂機制，是指實現某一功能的具體執行機構。

而策略，則是在機制基礎上，借助于某些參數和算法來實現該功能的優化，或達到不同的功能目標。通常，機制處于一個系統的基層，而策略則處于系統的高層。

在程序設計中，機制與策略分離的思想可以提高程序的可復用性，可維護性和可調試性使程序更具有高內聚低耦合性。如果說機制是磚，那么策略就是房子，同樣的磚可以建不同的房子，我們不能把建磚和建房子混在一起實現。

策略的變化要遠遠大于機制的變化。將兩者分離，可以使機制相對保持穩定，而同時支持策略的變化。

在代碼大全中提到“隔離變化”的概念，以及設計模式中提到的將易變化的部分和不易變化的部分分離也是這個思路。

在《Unix編程藝術》第一章就深刻討論這個編程哲學：“在我們對 Unix 錯誤的討論中，我們觀察到 X window的設計者做出了一個基本決定來實現“機制，而不是策略” —— 使 X 成為一個通用的圖形引擎，并將有關用戶界面風格的決定留給工具包和其他級別的系統。我們通過指出政策和機制傾向于在不同的時間尺度上發生變異來證明這一點，政策的變化比機制快得多，GUI 工具包的外觀和感覺上的時尚可能來來去去，但光柵操作和合成是永恒的。

因此，將策略和機制硬連接在一起會產生兩個負面影響：它使策略變得僵化并且更難以響應用戶需求而改變，這意味著試圖改變策略有很強的破壞機制穩定的傾向。

另一方面，通過將兩者分開，我們可以在不破壞機制的情況下試驗新策略。我們還使為機制編寫好的測試變得更加容易。

實現這種分離的一種方法是，例如，將應用程序編寫為由嵌入式腳本語言驅動的 C服務例程庫，應用程序控制流是用腳本語言而不是 C 編寫的。這種模式是Emacs編輯器，它使用嵌入式 Lisp解釋器來控制用 C 編寫的編輯原語。

另一種方法是將您的應用程序分成協作的前端和后端進程，這些進程通過套接字上的專用應用程序協議進行通信；前端執行策略，后端實現機制。這樣的全局復雜性通常遠低于實現相同功能的單進程單體的復雜性，從而減少您對錯誤的脆弱性并降低生命周期成本（提高健壯性）。”

一些例子GUI框架

MVC（Model-View-Controller）作為最經典的GUI架構，MVC模式的核心思想是數據層（Domain）與表現層（Presentation）的隔離。

模型（Model） 用于封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。“ Model ”有對數據直接訪問的權力，例如對數據庫的訪問。“Model”不依賴“View”和“Controller”，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中數據的變化一般會通過一種刷新機制被公布。為了實現這種機制，那些用于監視此 Model 的 View 必須事先在此 Model 上注冊，從而，View 可以了解在數據 Model 上發生的改變。

視圖（View）能夠實現數據有目的的顯示（理論上，這不是必需的）。在 View 中一般沒有程序上的邏輯。為了實現 View 上的刷新功能，View 需要訪問它監視的數據模型（Model），因此應該事先在被它監視的數據那里注冊。

控制器（Controller）起到不同層面間的組織作用，用于控制應用程序的流程。它處理事件并作出響應。“事件”包括用戶的行為和數據 Model 上的改變。

View，Model屬于策略，在系統中屬于可變部分，Controller屬于機制，不會隨著view的變化而變化，屬于系統中不變的部分，構建一個系統要盡肯能分離可變部分和不可變部分。

netfilter框架

netfilter框架是一個典型將機制和策略分離好例子：

Netfilter是一個設計良好的框架，之所以說它是一個框架是因為它提供了最基本的底層支撐，而對于實現的關注度卻沒有那么高，這種底層支撐實際上是5個HOOK點：

PREROUTING：數據包進入網絡層路由前FORWARD：數據包路由之后確定要轉發之后INPUT：數據包路由之后確定要本地接收之后OUTPUT：本地數據包發送POSTROUTING：數據包發出去之前

Netfilter擁有幾乎無限的可擴展性， Liuux中使用的僅僅是它的一個很小的部分，大部分的內容作為可插拔的module處于待命狀態Netfilter的機制集成在Linux內核中， 然而它的策略擴展卻處于一個獨立的空間，我們說這種所謂的機制也僅僅是5個HOOK點。

我們瀏覽netfilter.org就會知道，它里面融合了大量的策略，我們最熟悉的就是iptables了，上圖的ebtables，arptables，nft也是Netfilter的擴展之一， 足以看出，Netfilter有多強大，內核僅僅給出鉤子點而已， 如果你嫌某些不好，你可以自己實現一個更好的，事實上，Netfilter中有很多的東西并沒有集成在Linux內核。

TCP擁塞控制框架

Linux系統中的TCP擁塞控制采用面向對象的設計思想，提供擁塞控制接口用于實現不同的擁塞控制策略，成功把擁塞控制解耦了：

內核實現BPF虛擬機執行核心引擎，屬于機制部分；

用戶態可以編寫各種BPF程序，實現不同策略功能；

游戲引擎

游戲引擎便是專門為游戲而設計的工具及技術集成，之所以稱為引擎，如同交通工具中的引擎，提供了最核心的技術部分--游戲機制，然后可以通過腳本語言或者關卡設計來插入策略邏輯，重用性是游戲引擎的一個重要設計目標，這樣很多游戲開發都可以通過“換皮策略”來快速開發新游戲。

最后一些問題1、透過現象看本質，機制與策略到底是什么？為什么要將機制與策略分離？

機制可以認為是業務通用的核心模型（框架），不易變化；策略可以認為是某個功能的具體實現方案，可以被框架使用；機制與策略分離，是一種可擴展性設計的重要方法，提供一個繼承接口，用于提供不同的實現，這也就是策略模式和接口隔離原則。機制關聯一個抽象的策略（也就是接口），用不同的具體策略初始化抽象策略，就能調用具體策略的處理流程。

2、假如不分離，會出現什么問題？

把策略同機制揉成一團有兩個負面影響：一來會使策略變得死板，難以適應用戶需求的改變，二來也意味著任何策略的改變都極有可能動搖機制，對原來穩定的框架造成污染，引入風險。

所以我們在設計系統的時候，可以參考這種機制和策略模式，讓系統具有更好的擴展性和更好的穩定性。

參考和擴展閱讀https://web.archive.org/web/20050306210911/http://www.faqs.org/docs/artu/ch01s06.html#id2877777

https://qcc107.github.io/2015/09/01/UNIX%E7%BC%96%E7%A8%8B%E8%89%BA%E6%9C%AF%E4%B9%8B%E7%AD%96%E7%95%A5%E4%B8%8E%E6%9C%BA%E5%88%B6%E7%9B%B8%E5%88%86%E7%A6%BB/#：~：text=%E6%89%80%E8%B0%93%E6%9C%BA%E5%88%B6%EF%BC%8C%E6%98%AF%E6%8C%87%E5%AE%9E%E7%8E%B0，%E5%86%85%E8%81%9A%E4%BD%8E%E8%80%A6%E5%90%88%E6%80%A7%E3%80%82

編輯：jq