1、Linux程序設計模式一機制與策略什么是設計模式(Design pattern )?設計模式(Design pattern )是一套被反復使用、多數人知曉的、經過分類編目的、軟件設計經驗的總結。使用設計模式是為了提高代 碼或模塊的重用、讓程序更容易被他人理解、提高代碼可靠性和可維護性。同時，通過學習設計模式可以降低解決一般性 問題的開發難度。LinUX程序設計模式的起源和 發展LinUX程序的設計模式起源于 Unix文化，是Unix哲學的重要 組成部分，而Linux本身就是Unix的一個發展分支。Unix哲學說來不算是一種正 規設計方法，它是自下而上的，而不是自上而下的。Unix哲學注重 實效

2、，立足于豐富的 經驗。你不會在正 規方法學和 標準中找到它，它更接近于 隱性的半本能的知識，即Unix文化所傳播的專業經驗。它鼓勵那種分清 輕重緩急的感覺，以及懷疑一切的態度，并鼓勵你以幽默達觀的態度對待這些。什么是Unix哲學?Unix管道的發明人、Unix傳統的奠基人之一 Doug McIlroy 在Mcllroy78中曾經說過：I.讓每個程序就做好一件事。如果有新任 務，就重新開始，不要往原程序中加入新功能而搞得復雜。II.假定每個程序的 輸出都會成為另一個程序的輸入，哪怕那個程序 還是未知的。輸出中不要有無關的信息干 擾。避免使用嚴格的分欄格式和二進制格式輸入。不要堅持使用交互式輸入。

3、Ill.盡可能早地將 設計和編譯的軟件投入試用，哪怕是操作系 統也不例外，理想情況下，應該是在幾星期內。對拙劣的代碼別猶豫，扔掉重寫。IV.優先使用工具而不是拙劣的幫助來減 輕編程任務的負擔。工欲善其事，必先利其器。后來他這樣總結道(引自Unix的四分之一世 紀)：Unix哲學是這樣的：一個程序只做一件事，并做好。程序要能協作。程序要能 處理文本流，因為這是最通用的接口。從整體上來 說，可以概括為以下幾點:01.模塊原則使用簡潔的接口拼合 簡單的部件。06.吝嗇原則除非確無它法，不要 編寫龐大的程序。02.清晰原則 清晰勝于機巧。03.組合原則設計時考慮拼接組合。04.分離原則策略同機制分離，

4、接口同引擎分離。05.簡潔原則設計要簡潔，復雜度能低則低。07.透明性原則：設計要可見，以便審查和調試。08.健壯原則：健壯源于透明與 簡潔。09.表示原則：把知識疊入數據以求 邏輯質樸而健壯。10. 通俗原則：接口設計避免標新立異。11. 緘默原則：如果一個程序沒什么好 說的，就沉默。12. 補救原則：出現異常時，馬上退出并給出足夠錯誤信息。13. 經濟原則：寧花機器一分，不花程序 員一秒。14. 生成原則：避免手工hack，盡量編寫程序去生成程序。15. 優化原則：雕琢前先要有原型，跑之前先學會走。16. 多樣原則：決不相信所 謂“不二法、丁的斷言。17. 擴展原則：設計著眼未來，未來 總

5、比預想來得快。給大家推薦一本 書UNIX編程藝術這不是一本 講如何編程的書，而是一本 講UNIX設計哲學的書，當然也適應于LinUX。這本書是我來威勝工作后，同事 們推薦我讀的第二 本書（范律推薦）。第一本書是UNIX環境高級編程（邱云松推薦），第三本書是UNIX網絡 編程第2卷進程間通信（張棟推薦），第四本書是LinUX設備驅動程序第三版（劉利 方推薦），第五本書是linux程序設計第三版（我推薦）。什么是機制與策略?我們通過下面文字來理解什么是機制與策略:設備驅動程序的作用在于提供機制，而不是提供策略。X（wi ndows）致力于提供一套機制，而不是策略。策略相對短壽，而機制才會 長存。前

6、端實現策略，后端實現機制。策略和機制是按照不同的 時間尺度變化的，策略的 變化要遠遠快于機制。把策略同機制揉成一 團有兩個負面影響：一來會使策略 變得死板，難以適應用戶需求的改 變，二來也意味著任何策略的改變都極有可能動搖機制。相反，將兩者剝離，就有可能在探索新策略的時候不足以打破機制。另外，我 們也可以更容 易為機制寫出較好的測試（因為策略太短命，不 值得花太多精力在 這上面）。機制與策略的實例:（下面的講解過程中，我會提出一些 問題。如果回答錯誤將會有一個小小的 懲罰）1.Uboot 的環境變量(bootcmd)2.L in UX驅動程序(exa mp les/scull)3. cmdli

7、ne 中的mtdparts解析程序4.udev 的rules 文件自動執行U盤腳本(60-removable-storage.rules) 5.udev 的net.agent ,實現USB網卡的自動掛接(80-drivers.rules) 6.BusyBox 工具集介紹(sed , awk ,inetd ， chat ， crond ， find ， grep ， getty-login-bash， start-stop- daemon , run-parts7. 嵌入式數據庫(TokyoCabi net，Sqlite3)8. 腳本語言(SHELL, TCLSH，Lua，TCC，python)

8、9. 圖形界面庫(qt,p yGTK)MCU嵌入式系統中的機制與策略:MCU（Micro Control Unit，微控制器單元）片上集成外圍器件，沒有外擴總線，不帶MMU 單元是其的主要特征，比如ARM7，Cortex-M3 系列等。與之相對的是MPU （MicroProcessor Unit，微處理器單元）不帶外圍器件（例如存儲器），是高度集成的通用結構的處理器，比如ARM926，Cortex-A8 系列等。在資源非常緊張的深度嵌入式系 統中，同樣也有使用機制與策略 設計模式的成功案例與成熟 方案。例如:1.p Forth ，eForth ， RetroForthForth是六十年代末期，

9、由Charles H. Moore發展出來在天文臺使用的電腦自動控制系統及程序設計語言，允許使用者很容易 組合系統已有的簡單指令，定義成為功能較復雜的高階指 令。forth是一種可擴展的，交互式的 語言。最初為小型的嵌入式 電腦設計的，現在它幾乎可以 在任何主流的芯片上解譯和編譯，甚至已有多種可直接運行forth指令的芯片。2. Pawn, Paw n+freeRTOSAn embedded scri pti ng lan guage formerly called Small.pawn is a simple, typ eless, 32-bit exte nsion lan guage w

10、ith a C-like syn tax. A pawn "source" p rogram is comp iled to a binary file for op timal executi on sp eed. The pawncomp ilerout putsP-code (or bytecode) thatsubseque ntlyruns on an abstract machine.Executionspeed, stability, simplicity and a smallfoot printwereesse ntialdesig n criteria

11、for both the lan guage and the abstract machi ne.3. eLua, nutlua(Lua+Nut/OS)eLua sta ndsfor Embedded Lua and the p rojectaims to offerthe fullimpl eme ntati onof the Lua P rogram mingLan guagetothe embeddedworld,exte nding itwithspecific features for efficient and portable software embeddeddevel opm

12、ent.Forth 、Pawn和Lua在其他領域的應用:Infocom 高級游戲開發者FIG-Forth編寫的。按他們技術總監Marc de Groot的說法，把一個基于 Z80的游戲移植到6502 或者 MC6809 上,典型的時間不多于3個月。美國 Federal Express（聯邦快遞）公司的手持式行李分 撿系統的程序是用Forth編寫的。項目經理Gene Farrar說，他可以按需要在幾個星期內升 級新固件，相比而言，其它的小組維護C語言代碼則至少需要6個月的時間。1990年11月哥倫比亞航天飛機的4個載荷中有3個是用Forth編程的。按設計團隊之一 Johns Hopkins Un

13、iversity's Applied Physics Laboratory 的 JohnHayes說法，他們選擇Forth來解決飛行中的硬件問題，靈活性是一個主要的因素。SUN公司把Forth用于它的工作站可 編程Boot ROM中，以每天500-1000臺的速度 發貨，是可 編程Forth系統中數量最大的。1994年IEEE 1275-1994將Forth用于BOOT（初始配置） 固件的標準，這也是POWER PC通用硬件平臺的基 礎。在電影終結者II :世界末日中，Cyberdyne Systems T1000系統的特技效果是基于Morphing 軟件包Forth產生的。著名的第一

14、人稱射 擊類游戲CS反恐精英就是使用了 Pawn腳本語言來控制游戲。而另兩款著名的3D即時策略類游戲魔獸爭霸3和RPG類在線游戲魔獸世界中也大量使用lua腳本。還有在移動設備上一直很火熱的游戲憤怒的小鳥也使用lua腳本。機制與策略設計模式在游戲中的應用是最為廣泛的，常常關卡的 設計和場景的變換都是利用腳本語言來完成策略部分。而畫面的渲染和 動畫的著色這交給圖形引擎庫來完成機制功能。Termi nal中的機制與策略:Atari的許多投幣游戲機都是用Forth開發的。他們相信開發高性能代碼的最快方法是使用Forth，加上使用 匯編語言來重寫最內 層的循環。按照最近與著名的 的談話，他們的游戲解釋器

15、也是用Forth寫成的。Unison World為CP/M操作系統開發了許多游戲，全部都是用Termin al平臺大量使用了機制與策略的 設計模塊。在這些方案中，有些做到很 簡單，有些 則做得很靈活。但不管怎 樣，它們都為解決實際問題做出了重要的貢獻。1. analysis 統計分析模塊實時庫中的部分數據是通 過分析計算從電表上采集的數據而得來的，Analysis.ini就是用來 配置這些數據項以及這些數據項的處理方法。2. taskmanage任務管理任務管理的工作是在特定的 時間將實時庫中的數據轉存到數據庫中。從而生成 對應的日月凍 結數據、曲線數據等等。這些數據在376.1規約中被稱為二

16、類數據。3. cparam 參數管理參數管理使用的是gdbm+xml的配置方式，主要 實現規約解析要求的各類參數，同 時也管 理部分內部參數。db2xml和xml2db兩個工具實現參數文件格式的 轉換。4. dbmanage 數據管理數據管理使用的是sqlite數據庫，并且將運行時的數據庫創建也做成了配置文件的形式。通 過修改和增加配置文件的內容就能 擴展終端運行時的數據庫。5. shmemory 實時庫模塊實時庫的創建是通過定義C語言中對應的結構體數組來完成的。它提供了抄表程序、統計 分析和任務管理需要使用到的數據 項，以及這些數據項在共享內存中保存的空 間。6. readmeter總表抄表

17、模塊抄表模塊根據readmeter.ini的配置信息決定哪種 電表類型抄讀哪些數據項。配置文件中的 數據項已擴展成為內部規約，與電表規約中的數據項已無 對應的關系。7. menu菜單界面模塊shift-ac mp .xml,shift-菜單界面顯示內容是通 過XML文件格式來配置的，其中包括auto.xml,menu.xml三大部分，各地的差異通 過變量LOCALE區分開來。8. prop arse 規約解析模塊規約解析使用了兩套配置文件ini和xml。前者用于配置 AFN&FN的數據解析，后者是根據各地情況使用插件 對差異項進行配置。前者配置文件 還與實時庫和數據庫有關聯。9. Ta

18、skManage 抄表管理抄表管理模塊開始時使用ini文件配置，后轉為gdbm+xml方式。配置文件主要是 設置定 時抄讀的數據項，這其中使用了一套內部 標識，抄讀上來數據直接保存到數據 庫。10. TaskExecutor抄表執行抄表執行模塊使用了 ini文件配置，實現內部標識到電表規約數據標識的轉換。抄表程序根據電表標識抄讀電表的數據，根據內部 標識保存從電表抄讀上來的數據。11. watchdog運行程序監控通過watchdog.conf配置文件決定要啟 動哪些程序，以及 這些程序的執行方式。當有程序 異常退出時，watchdog需要根據配置文件再次啟 動這些程序。盡管從開發技術的角度看

19、，機制與策略在 Terminal平臺上的應用是成功的，但是從 維護管 理的角度看，這些應用考慮得卻不是很夠。有以下幾點原因：1.策略沒有形成 統一的風格。各模塊之間的配置風格迥異，沒有一位開 發員敢說已經掌握了所有模 塊的配置。掌握 這些配置的學習曲線很高，有些模 塊的配置文件甚至比代 碼還難搞懂。幫助文檔也相當滯后，開 發人員基本沒有整理這類相關的文檔或手冊。2.所以注定這類策略只能由開 發模塊的人員自己維護。解析策略的機制各有千秋。我們的配置文件有sqlite格式的、gdbm格式的、xml格式的、ini格式的、自定義格式的、自定義C語言結構數組等等，這樣情況最終導致 了代碼的冗余，同時抬高

20、了代碼維護的成本。各類配置文件的解析性能也參差不 齊, 程序對修改的監控也只是輪詢方式，也有些配置文件使用起來 還比較麻煩，需要經過 幾次轉換才能生效。3.機制與策略分離不夠徹底。部分模塊的策略沒有完全從機制中分離出來，其中或多或4.5.少還是存在一些特殊了機制與策略模式的處理的情況。這些特殊處理是對需求不確定的保留，同 時也破壞設計原則，直接的壞處是影響到代 碼的維護，有時一個新的功能需要修改多處代碼和配置文件才能 實現。策略僅僅是低層次的配置。大部分模塊設計的策略僅僅是停留在簡單設置，沒有什么邏輯上的功能，或者 說它不像是腳本更像是配置， 這種思路限制了策略的靈活性。但 是如果要提高策略的

21、 處理層次，勢必需要設計更復雜的處理程序。而事 實上，另外一個原因是參與開發的人員也缺乏相關的經驗。借鑒開源項目的經驗不足。設計一套優秀的機制與策略的模式需要花 費不少時間和精力，而一般項目不可能會有如此集中的投入。在此情況下本 應該最大可能的借鑒開源項目的代碼，但實際上我們卻沒有這么做，而是 選擇重新發明新的輪子，盡管這樣做也可以實現功能，但是我們并沒有從中獲得好處。目前的情況并不是 項目缺乏機制與策略模式的運用，而是 對這種模式運用太多太 雜，而且總體技術水平偏低，維護成本又偏高。就好比花了很大的力氣和很多的時間，卻搞了大量的低 層次的重復建 設一樣。現在term in al平臺已經逐漸穩

22、定下來，如果再 進行大的改進必定是違背了經濟原則，維護成本也會隨之陡增。 這就是設計規劃欠下債，越往后 償還代價越大。而就目前的情況來 說，我們最重要的不是忙著考 慮如何還債，而是要 讓大家學會如何才能不欠下新的債。這樣終有一日欠債才可能真正還清。機制與策略的測驗:現在我們開始做一個體 驗項目，目的是通 過這個項目深刻理解機制與策略的特點，并能夠將其內涵轉化為自己的思想，同 時運用到實際的工作中。以下是 項目的一些情況:項目名稱：遠程升級工具（upgrade ）項目經理：（負責考核成員，以及分配任 務）項目成員：（參與培訓的所有員工，分為12人一組）開發時間：（有效工時兩周）項目背景:剛來公司

23、不久的小蔣最近接到一個棘手的新任 務。這一次領導要求他開發一個用于給2000臺集中器進行遠程升級的軟件工具。但由于 時間緊迫，他必須在兩周時間內完成，并且 還要馬上出差去現場調試。下面的一段 對話描述了當時的情況:小蔣:領導:'這事看起來很困難，兩周時間內完成似乎不可能?！薄笆堑?，所以你要想辦法，在現有的測試系統上改，這樣做會快一些。”“那套代碼我完全不熟，況且系 統文檔不全，編程也非常不 規范，很多地方完全搞不 懂。我還是要先好好熟悉一下吧?！毙∈Y:領導：“沒有那么多考慮的時間，你趕緊去辦吧。”雖然小蔣很委屈，也 給自己找了很多理由，但最后 還是得接下這個任務。從上面的對話可以看出，

24、領導可能并不了解事情的真相，要在 現有的系統上改一改就能用，那只是在理想狀態下，如果開 發人員對原有代碼不夠熟悉，可能會犯更多的 錯誤從而將時間花費在反復調試和修 改中。當然，我 們也了解到這個項目確實很麻煩，首先，小蔣 對于維護這套代碼缺乏必要的自信；其次，拋棄它又更需要足夠的勇氣。如果 這個任務交給你，現在又該如何做呢?（嗯，我想我別無選擇。因為我甚至都不知道那個糟糕的測試系統長啥樣。）項目名稱：通信報文解析器（msgdump ）項目經理：（負責考核成員，以及分配任 務）項目成員：（參與培訓的所有員工，分為12人一組）開發時間：（有效工時兩周）項目背景:最近新手小 趙遇到一個 煩心的問題，

25、每次分析或 調試終端時都會遇到要解析 通信報文的問題。他希望能夠有一個 這樣的小工具：能夠 解析主站與終端或終端與電表之間的通信報文。這件事很有意義，因為手動分析十六 進制通信報文不僅費勁、速度慢而且容易岀 錯。他在自己的日 記中是這樣描述的： “我快發瘋了。今天同時接到5現場技支人員的電話，其中2個要求分析終端與主站通信的 問題，3個要求分析終端抄表的問題。而他們都提供的一堆十六 進制通信報文足夠我分析2兩天了，我簡直就成了分析 報文 的工具。這種事情難道不能交給機器來做嗎？“多么美好的事情。甚至不需要我 們岀馬，靈活，既可以在 PC機上使用，又可以在分析報文的工作交 給這個小工具來完成。這

26、就是我們想要的：一款通用的 報文解析器?，F場工程人員就能輕松搞定。當然， 這樣的軟件工具應該設計 得非常終端中運行。而 終端中的應用也只要提供接口或者管道 連接，就能將開發步驟：第一步，確定目 標。用幾句簡短的話概括性的說清楚自己要做的事或 對開發軟件的描述。目標要明確且務實，如果目標不實際，寧可降低一些也要保 證切實可行。第二步，分析需求。 使用TodoList or MindMaps的方式羅列出軟件需要開發的功能點,想得越多表明你考 慮得越全面。除此之外，我 們還要羅列出相關的測試工作和準備工作等等。第三步，設計方案。進一步分解需求，并 評估每一項工作任務的時間投入和任務規模。最后對所有的工作任 務進行優先級排序，并根據實際情況設立項目各階段的里程碑。第四步，實現功能。所有功能點應該按照里程碑的要求分 階段實現，并且遵循“短，平，快”的原則。盡可能早的發布中間版本，讓測試與研發的工作能夠并行起來。第五步，開始