市面上的“設(shè)計模式“書籍文章，皆針對Java/C++/C#等面向?qū)ο笳Z言，似乎離開了面向?qū)ο蟮姆N種特性，設(shè)計模式就無法實(shí)現(xiàn)，沒有用武之地了。
是這樣嗎？設(shè)計模式的概念是從建筑領(lǐng)域引入的，本身從沒歧視過面向過程編程語言，它只是對一類問題的普遍解決方案而已。面向?qū)ο笳Z言因?yàn)橛蓄悺⒍鄳B(tài)等特點(diǎn)，使得開發(fā)者們?nèi)菀走_(dá)到：隱藏細(xì)節(jié)、封裝變化，而這與設(shè)計模式的目的比較一致，所以大師們愛把設(shè)計模式與面向?qū)ο笳Z言二位一體的使用。然而，存在即合理，C語言直到今日仍然在大型軟件工程中擔(dān)綱主角，其種種設(shè)計方法其實(shí)與我們通常見到的設(shè)計模式本質(zhì)是相同的。例如nginx這個純C語言寫就的的高性能WEB服務(wù)器，就有許多地方使用到了市面書籍提到的設(shè)計模式。下面通過nginx源碼來看看C語言是怎么做的。當(dāng)然，UML圖都是我根據(jù)代碼意圖所畫，并不準(zhǔn)確（C語言真沒法畫UML），只用于方便理解，呵呵。
strategy模式：
該模式用于客戶代碼在“無知”狀態(tài)下，可以使用種種不同的實(shí)現(xiàn)。下面我們以nginx對網(wǎng)絡(luò)IO操作的封裝部分來看看C語言的實(shí)現(xiàn)吧。
設(shè)計模式就是通過封裝變化來解耦，所以，我們先要找出網(wǎng)絡(luò)IO操作的變化點(diǎn)來。nginx是跨平臺的，它會支持linux、freebsd、solaris等操作系統(tǒng)，而每個操作系統(tǒng)的網(wǎng)絡(luò)IO操作是不同的，這就是變化點(diǎn)了。
所以，nginx首先定義了ngx_os_io_t來封裝這些變化。
- typedef struct {
- ngx_recv_pt recv;
- ngx_recv_chain_pt recv_chain;
- ngx_recv_pt udp_recv;
- ngx_send_pt send;
- ngx_send_chain_pt send_chain;
- ngx_uint_t flags;
- } ngx_os_io_t;
這里有五個函數(shù)指針（*_pt都是函數(shù)指針）和一個變量，用于收發(fā)網(wǎng)絡(luò)數(shù)據(jù)，我把它理解為OO中的abstract class（每個ngx_os_io_t定義的變量都會重新實(shí)現(xiàn)這五個函數(shù)）。
擁有函數(shù)指針的struct，我通常認(rèn)為它們是OO中的abstract class，實(shí)現(xiàn)它們的文件（一堆函數(shù)）要對應(yīng)到OO上，我則喜歡把它們當(dāng)做子類來看。對于void*這樣的成員，要根據(jù)意圖來看了，通常我會轉(zhuǎn)換成聚合加繼承的關(guān)系。
ngx_io會在相應(yīng)的ngx_os_specific_init方法中，來策略性的選擇到底使用哪個實(shí)現(xiàn)。客戶代碼只需要簡單的調(diào)用ngx_io中的方法即可。
adapter模式：
這個模式用以適配接口，通常都是我們已經(jīng)定義好一種接口了，有一個新的實(shí)現(xiàn)卻有著不同的接口，接下來adapter就開始發(fā)力了。下面我們?nèi)匀灰詎ginx對網(wǎng)絡(luò)IO操作的封裝部分來看。
linux平臺下可能存在普通的IO或者異步IO方式。我們在最初已經(jīng)封裝好ngx_os_io_t接口了，客戶代碼都是這么直接使用的。現(xiàn)在linux實(shí)現(xiàn)了異步IO，而它的調(diào)用方式與普通的讀寫IO接口完全不同，所以，如果要支持aoi就需要一層adapter來適配ngx_os_io_t，這就是adapter方式了。
上圖中，ngx_os_aio適配了原生的異步IO接口，這樣，用戶代碼仍然像以前一樣，只要直接使用ngx_io中的五個接口方法，當(dāng)nginx的IO部分支持linux aio后，用戶代碼不需要修改。
bridge橋模式：
橋模式用于將抽象和實(shí)現(xiàn)分離，各自都能獨(dú)立的變化。下面以nginx的核心概念module舉例，雖然有些牽強(qiáng)，因?yàn)閚ginx的代碼從來沒這么用過：通常都是一個抽象module context只對應(yīng)著一個實(shí)現(xiàn)module來用，但是，畢竟這種結(jié)構(gòu)下還是可以達(dá)到抽象與實(shí)現(xiàn)分離的目的，橋模式只好對應(yīng)到這上面了。
nginx是以module的概念貫穿始終的。它有一個基本的抽象層ngx_core_module_t（從意圖上判斷，context有抽象接口的功能，雖然簡單從語法上看不出）。然后，nginx module有三個基本類型，分別是event（處理各種事件模型，如epoll/select等），http（處理各種http協(xié)議的事件），mail（處理mail相關(guān)的事件）。針對每種類型的module，都有許多個實(shí)現(xiàn)，比如event module就有9個實(shí)現(xiàn)，這里的每個實(shí)現(xiàn)其實(shí)也是個子類。
但是，在我們理解橋模式時，這些子類暫時要被看成是event module的實(shí)例。代碼中看，像ngx_epoll_module這樣的子類中，還是把一些通用的細(xì)節(jié)隱藏給ngx_event_core_module來做（管理這個詞更合適）了。從這個角度可以認(rèn)為，通過context接口，把三個基本module實(shí)現(xiàn)分開了。來看看類圖：
nginx自己用時，是以ngx_module_t中的type成員來決定使用哪個實(shí)現(xiàn)的。目前的nginx代碼中，如果用了一種接口就一定會指定相應(yīng)的type。可是實(shí)際上，這也可以用來展示橋模式。以事件module為例來看看：
由于UML本就是針對OO語言的，所以以上我畫的類圖都比較牽強(qiáng)，什么是繼承？什么是聚合？在C語言中，往往都是通過幾個函數(shù)指針，或者void*指針實(shí)現(xiàn)各種封裝和多態(tài)。沒有什么語法上的關(guān)聯(lián)，我就只能從代碼意圖中來判斷了。而代碼意圖這個比較虛，因?yàn)椴煌慕嵌壤斫獬鰜矶疾灰粯樱赃@個確實(shí)不好畫。太靈活了點(diǎn)，我只能從一個便于說明的角度來看，例如：上面的ngx_devpoll_module其實(shí)就是一個ngx_module_t，呵呵，但是，實(shí)際上它最關(guān)心的是ngx_event_actions_t的實(shí)現(xiàn)，如果完全根據(jù)語法來看，根本說不通的。但從代碼意圖中看，這些module并不關(guān)心ngx_module_t，所以我認(rèn)為，它們只是在實(shí)現(xiàn)ngx_event_module_t了。
當(dāng)然以上只是一家之言，不必當(dāng)真，如果對nginx源碼有研究的話，歡迎各位拍磚。
客觀的說，C語言確實(shí)在封裝上很差，就像nginx，如果我們要開發(fā)一個處理http協(xié)議的module嵌入進(jìn)nginx進(jìn)程，必須了解ngx_http_module里到底做了什么，真沒隱藏啥細(xì)節(jié)，module開發(fā)者們表示很郁悶。上面的這些設(shè)計模式，只是做到了代碼上的解藕。如果nginx用C++寫的話，我相信，現(xiàn)在第三方module都能數(shù)以萬計了。
原文地址：
http://blog.csdn.net/russell_tao/article/details/7220237