在現(xiàn)代操作系統(tǒng)的結(jié)構(gòu)設(shè)計(jì)中，經(jīng)常利用“機(jī)制與策略分離”的原理來(lái)構(gòu)造OS結(jié)構(gòu)。所謂機(jī)制，是指實(shí)現(xiàn)某一功能的具體執(zhí)行機(jī)構(gòu)。

而策略，則是在機(jī)制基礎(chǔ)上，借助于某些參數(shù)和算法來(lái)實(shí)現(xiàn)該功能的優(yōu)化，或達(dá)到不同的功能目標(biāo)。通常，機(jī)制處于一個(gè)系統(tǒng)的基層，而策略則處于系統(tǒng)的高層。

在程序設(shè)計(jì)中，機(jī)制與策略分離的思想可以提高程序的可復(fù)用性，可維護(hù)性和可調(diào)試性使程序更具有高內(nèi)聚低耦合性。如果說(shuō)機(jī)制是磚，那么策略就是房子，同樣的磚可以建不同的房子，我們不能把建磚和建房子混在一起實(shí)現(xiàn)。

策略的變化要遠(yuǎn)遠(yuǎn)大于機(jī)制的變化。將兩者分離，可以使機(jī)制相對(duì)保持穩(wěn)定，而同時(shí)支持策略的變化。

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

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

因此，將策略和機(jī)制硬連接在一起會(huì)產(chǎn)生兩個(gè)負(fù)面影響：它使策略變得僵化并且更難以響應(yīng)用戶(hù)需求而改變，這意味著試圖改變策略有很強(qiáng)的破壞機(jī)制穩(wěn)定的傾向。

另一方面，通過(guò)將兩者分開(kāi)，我們可以在不破壞機(jī)制的情況下試驗(yàn)新策略。我們還使為機(jī)制編寫(xiě)好的測(cè)試變得更加容易。

實(shí)現(xiàn)這種分離的一種方法是，例如，將應(yīng)用程序編寫(xiě)為由嵌入式腳本語(yǔ)言驅(qū)動(dòng)的 C服務(wù)例程庫(kù)，應(yīng)用程序控制流是用腳本語(yǔ)言而不是 C 編寫(xiě)的。這種模式是Emacs編輯器，它使用嵌入式 Lisp解釋器來(lái)控制用 C 編寫(xiě)的編輯原語(yǔ)。

另一種方法是將您的應(yīng)用程序分成協(xié)作的前端和后端進(jìn)程，這些進(jìn)程通過(guò)套接字上的專(zhuān)用應(yīng)用程序協(xié)議進(jìn)行通信；前端執(zhí)行策略，后端實(shí)現(xiàn)機(jī)制。這樣的全局復(fù)雜性通常遠(yuǎn)低于實(shí)現(xiàn)相同功能的單進(jìn)程單體的復(fù)雜性，從而減少您對(duì)錯(cuò)誤的脆弱性并降低生命周期成本（提高健壯性）。”

一些例子GUI框架

MVC（Model-View-Controller）作為最經(jīng)典的GUI架構(gòu)，MVC模式的核心思想是數(shù)據(jù)層（Domain）與表現(xiàn)層（Presentation）的隔離。

模型（Model） 用于封裝與應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)以及對(duì)數(shù)據(jù)的處理方法。“ Model ”有對(duì)數(shù)據(jù)直接訪(fǎng)問(wèn)的權(quán)力，例如對(duì)數(shù)據(jù)庫(kù)的訪(fǎng)問(wèn)。“Model”不依賴(lài)“View”和“Controller”，也就是說(shuō)， Model 不關(guān)心它會(huì)被如何顯示或是如何被操作。但是 Model 中數(shù)據(jù)的變化一般會(huì)通過(guò)一種刷新機(jī)制被公布。為了實(shí)現(xiàn)這種機(jī)制，那些用于監(jiān)視此 Model 的 View 必須事先在此 Model 上注冊(cè)，從而，View 可以了解在數(shù)據(jù) Model 上發(fā)生的改變。

視圖（View）能夠?qū)崿F(xiàn)數(shù)據(jù)有目的的顯示（理論上，這不是必需的）。在 View 中一般沒(méi)有程序上的邏輯。為了實(shí)現(xiàn) View 上的刷新功能，View 需要訪(fǎng)問(wèn)它監(jiān)視的數(shù)據(jù)模型（Model），因此應(yīng)該事先在被它監(jiān)視的數(shù)據(jù)那里注冊(cè)。

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

View，Model屬于策略，在系統(tǒng)中屬于可變部分，Controller屬于機(jī)制，不會(huì)隨著view的變化而變化，屬于系統(tǒng)中不變的部分，構(gòu)建一個(gè)系統(tǒng)要盡肯能分離可變部分和不可變部分。

netfilter框架

netfilter框架是一個(gè)典型將機(jī)制和策略分離好例子：

Netfilter是一個(gè)設(shè)計(jì)良好的框架，之所以說(shuō)它是一個(gè)框架是因?yàn)樗峁┝俗罨镜牡讓又危鴮?duì)于實(shí)現(xiàn)的關(guān)注度卻沒(méi)有那么高，這種底層支撐實(shí)際上是5個(gè)HOOK點(diǎn)：

PREROUTING：數(shù)據(jù)包進(jìn)入網(wǎng)絡(luò)層路由前FORWARD：數(shù)據(jù)包路由之后確定要轉(zhuǎn)發(fā)之后INPUT：數(shù)據(jù)包路由之后確定要本地接收之后OUTPUT：本地?cái)?shù)據(jù)包發(fā)送POSTROUTING：數(shù)據(jù)包發(fā)出去之前

Netfilter擁有幾乎無(wú)限的可擴(kuò)展性， Liuux中使用的僅僅是它的一個(gè)很小的部分，大部分的內(nèi)容作為可插拔的module處于待命狀態(tài)Netfilter的機(jī)制集成在Linux內(nèi)核中， 然而它的策略擴(kuò)展卻處于一個(gè)獨(dú)立的空間，我們說(shuō)這種所謂的機(jī)制也僅僅是5個(gè)HOOK點(diǎn)。

我們?yōu)g覽netfilter.org就會(huì)知道，它里面融合了大量的策略，我們最熟悉的就是iptables了，上圖的ebtables，arptables，nft也是Netfilter的擴(kuò)展之一， 足以看出，Netfilter有多強(qiáng)大，內(nèi)核僅僅給出鉤子點(diǎn)而已， 如果你嫌某些不好，你可以自己實(shí)現(xiàn)一個(gè)更好的，事實(shí)上，Netfilter中有很多的東西并沒(méi)有集成在Linux內(nèi)核。

TCP擁塞控制框架

Linux系統(tǒng)中的TCP擁塞控制采用面向?qū)ο蟮脑O(shè)計(jì)思想，提供擁塞控制接口用于實(shí)現(xiàn)不同的擁塞控制策略，成功把擁塞控制解耦了：

內(nèi)核實(shí)現(xiàn)BPF虛擬機(jī)執(zhí)行核心引擎，屬于機(jī)制部分；

用戶(hù)態(tài)可以編寫(xiě)各種BPF程序，實(shí)現(xiàn)不同策略功能；

游戲引擎

游戲引擎便是專(zhuān)門(mén)為游戲而設(shè)計(jì)的工具及技術(shù)集成，之所以稱(chēng)為引擎，如同交通工具中的引擎，提供了最核心的技術(shù)部分--游戲機(jī)制，然后可以通過(guò)腳本語(yǔ)言或者關(guān)卡設(shè)計(jì)來(lái)插入策略邏輯，重用性是游戲引擎的一個(gè)重要設(shè)計(jì)目標(biāo)，這樣很多游戲開(kāi)發(fā)都可以通過(guò)“換皮策略”來(lái)快速開(kāi)發(fā)新游戲。

最后一些問(wèn)題1、透過(guò)現(xiàn)象看本質(zhì)，機(jī)制與策略到底是什么？為什么要將機(jī)制與策略分離？

機(jī)制可以認(rèn)為是業(yè)務(wù)通用的核心模型（框架），不易變化；策略可以認(rèn)為是某個(gè)功能的具體實(shí)現(xiàn)方案，可以被框架使用；機(jī)制與策略分離，是一種可擴(kuò)展性設(shè)計(jì)的重要方法，提供一個(gè)繼承接口，用于提供不同的實(shí)現(xiàn)，這也就是策略模式和接口隔離原則。機(jī)制關(guān)聯(lián)一個(gè)抽象的策略（也就是接口），用不同的具體策略初始化抽象策略，就能調(diào)用具體策略的處理流程。

2、假如不分離，會(huì)出現(xiàn)什么問(wèn)題？

把策略同機(jī)制揉成一團(tuán)有兩個(gè)負(fù)面影響：一來(lái)會(huì)使策略變得死板，難以適應(yīng)用戶(hù)需求的改變，二來(lái)也意味著任何策略的改變都極有可能動(dòng)搖機(jī)制，對(duì)原來(lái)穩(wěn)定的框架造成污染，引入風(fēng)險(xiǎn)。

所以我們?cè)谠O(shè)計(jì)系統(tǒng)的時(shí)候，可以參考這種機(jī)制和策略模式，讓系統(tǒng)具有更好的擴(kuò)展性和更好的穩(wěn)定性。

參考和擴(kuò)展閱讀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