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