Unix/Linux的接口設計有一句通用的格言“提供機制而不是策略”。
區別對待機制（mechanism）和策略（policy）是Unix設計中的一大亮點。大部分的編程問題都可以被切割成兩個部分：“需要提供什麼功能（機制）”和“怎樣實現這些功能（策略）”。如果程序可以由獨立的部分分別完成機制與策略的實現，那麼開發軟件就更加容易，也更加容易適應不同的需求。
開源--展現在我們面前的是數以千計的代碼，在那一行行的代碼背後，到底蘊藏着怎樣的設計思想，高手們曾怎樣苦思冥想？在一堆堆的代碼面前，有時候，我們很容易迷失曾經進來的入口，而調入符號、變量以及函數堆積而成的沼澤地。
操作系統的本質是什麼？管理者？亦或服務者？但歸根到底，操作系統是一個執行者。
執行用戶程序--所謂爲用戶服務；執行中斷--所謂爲外設服務；所謂系統調用--所謂解放程序員（姑且說它爲廣大的程序員服務，因爲程序員不再與繁雜的硬件打交道了）；執行內核線程--爲操作系統自身服務。而這些所有，它們執行的核心，無非是在恰當的時機，讓哪個對象（程序、線程、中斷服務程序、中斷的下半部分、系統調用）佔有CPU。換句話說，Unix/Linux抽象出對這些對象的執行機制：
程序的執行機制 -- 進程 ；
內核函數的執行機制 -- 線程；
中斷服務程序的執行機制 -- 中斷信號觸發；
中斷下半部的執行機制 -- softirq, tasklet, 工作隊列；
系統調用的執行機制 -- 軟中斷（int $0x80觸發）
從機制和策略的角度看問題，也許，你對曾經困惑的問題有豁然開朗之感。
如果說機制是一種框架，那麼，策略就是填充框架的一個個具體的實體。機制提供的是一種開放而寬鬆的環境，而策略就是在這個環境下賴以生存的生命個體。比如，我們編寫的一個程序，fork()以後，就成爲一個個進程的生命個體。而操作系統所提供給我們創建、執行以及結束進程的各種原語--fork(),exec(),exit()等是統管各種進程的機制。我們所創建進程的死活並不會影響機制本身。
如此看來，也許我們對原理之困惑有所醒悟。我們任何人在任何時候都可一調用fork()創建n多個進程。這樣一個簡單的fork()殼，想追根溯源者，剝開這個殼，可以看到其本質。fork()如果出現任何一個小的bug，直接影響到我們任何程序員和任何進程。
如此看來，也許我們對開發者所承擔的角色有所領悟。系統分析員和設計人員任重道遠。說道此，設計模式等系列的書，對於有志於從編碼走向設計的開發者或許有所啓發。