設計模式在某種程度上確實能夠改善我們的程序結構，使設計具有更好的彈性。也正是由于這個原因，會導致我們可能過度的使用它。程序結構具有過度的、不必要的靈活性和程序結構沒有靈活性一樣都是有害的。本文將分析過度的靈活性可能造成的危害，并且結合一些實例來闡述使用設計模式改善程序結構應遵循的原則。

　　1、介紹
　　本系列文章的前兩篇主要講述了如何使用設計模式來改善我們的程序結構，大家可以看到經(jīng)過調整的代碼具有了更大的彈性，更容易適應變化。讀者朋友可能也具有類似的經(jīng)驗，通過使用設計模式使得自己的軟件系統(tǒng)更加具有可擴展性和健壯性。但是，這樣就可能會造成一個結果：無論遇到任何問題，我們首先做的就是設法找到一個解決它的設計模式來，而不是解決問題的最簡潔的方法。

　　上面所述的就是過分使用設計模式的情況，它賦予了代碼過度的靈活性。大家往往對于僵化、拙劣的設計所導致的危害非常清楚，但是對于過度靈活的設計可能帶來的危害卻不是很重視。本文試圖從這個角度來談談使用設計模式改善程序結構應遵循的原則，使大家避免陷入過分使用設計模式的狀況。其中的一個關鍵議題就是：我們?yōu)槭裁匆�使用設計模式，到底什么樣的程序結構才是好的。

　　2、過分設計的危害
　　正是由于大家對于僵化的設計所造成的結果的恐懼，以及對于設計模式給我們的程序結構帶來的無比的彈性的贊嘆，才會導致過分的預先設計（up-front design）。原因很簡單：需求肯定是要變化的。所以，我們就需要給代碼一些更多的靈活性，使得它可以適應以后的變化。于是，我們在最開始的設計中，就針對需求的變化做了很多的假設，并把對于這些假設的支持放在代碼中。

　　如果對這些假設的預測是正確的，那么做的這一切都是值得的。不幸的是，對這些假設的預測很難是正確的。原因很簡單：需求是我們的客戶（一般是另外一個企業(yè)）提出的，但是作為一個現(xiàn)代的企業(yè)，要想生存，就要不斷的改變自己以適應日新月異的變化，所以客戶的需求肯定是要根據(jù)自身生存、發(fā)展的需要而不斷變化的，并且這些變化都是很難預測的，常常是客戶自己都不知道下一步該如何變化（如果都能夠被你預測到的話，這個公司肯定會高薪聘請你去做他們的CEO）。

　　如果預測是錯誤的話，第一個直接后果就是，浪費了寶貴的時間、資金。我們花了很多的時間在一些根本沒有任何用處的靈活性上，而這些時間本可以用來為系統(tǒng)增加新的功能或者修正錯誤。

　　過分靈活的代碼往往更加復雜、難以理解。其他的開發(fā)人員不得不花費很多的時間來理解這些本來可以去除的復雜性。必然導致代碼的維護、擴展困難（如果需求的變化和你的假設不同），項目的開發(fā)效率降低。

　　例如：發(fā)現(xiàn)一種計算有多個不同的方式， 不加思索就直接采用Strategy設計模式，而不是采用簡單、清楚的條件表達式的方法（if－else語句），那么就會導致結構的復雜（要增加好幾個類）。如果后來發(fā)現(xiàn)根本就沒有在增加新的計算方法方面的需求，或者更糟糕的是需求的變化是某幾個計算策略間要增加依賴關系，那么修改起來就會十分困難。系統(tǒng)中如果存在太多的這種沒有必要的靈活性，很可能最終的程序結構就會陷入冗余、混亂之中。

　　程序結構的靈活性是有代價的，這種代價往往是更多的復雜性或者造成系統(tǒng)不容易理解，需要我們在設計時進行權衡。

　　3、軟件開發(fā)的節(jié)奏
　　現(xiàn)在在軟件工程領域很活躍的一個組織是：敏捷社團，他們提出了一系列的敏捷方法（XP就是其中很著名的一種）。在敏捷方法中制定了一系列的策略、實踐來擁抱需求的變化。其目標是：使軟件以規(guī)范的節(jié)奏進展，最終保質、按時交付軟件產品�，F(xiàn)在已有很多使用這種方法成功的商業(yè)案例。

　　對于軟件開發(fā)的節(jié)奏可以描述如下：首先寫測試代碼，提出對于系統(tǒng)的功能需求，然后寫工作代碼滿足這個需求，重復這個過程直到實現(xiàn)系統(tǒng)的所有需求。在這個過程中間要頻繁的（一般是在增加新功能或者修正錯誤時）進行重構，去除冗余的、含糊的代碼，改善程序的結構，使得新功能的添加變得容易�？梢钥闯鲈谶@樣的軟件開發(fā)節(jié)奏中，沒有對需求的變化做什么預測（進行預測的主要原因是恐懼變化），而是以一種主動的姿態(tài)來擁抱變化，當目前的設計不能夠適應發(fā)生的變化時，大膽的進行重構（因為有頻繁測試保證，所以重構的風險是不大的）去適應新的變化。這種方式被稱為演化設計（evolutionary design），在參考文獻〔3〕中可以得到進一步的內容。

　　設計模式一般會成為重構的目標，但是為什么要這樣做？我們一定要重構到一個設計模式嗎？怎樣的程序結構才是好的呢？

　　4、關鍵是要展現(xiàn)設計意圖
　　現(xiàn)在有一個普遍的誤解就是：程序結構的靈活性越高越好，所以對程序結構改善的目標就是使它具有更高的彈性，這樣在未來需求發(fā)生變化時可以很容易的改變程序來適應這種變化。其實，結構的靈活性和結構的易更改性之間是有矛盾的。很明顯，結構越靈活相應的就會越復雜，越復雜就越不容易理解，不容易理解怎么會容易更改呢？參考文獻〔1〕中專門探討了這個問題，有興趣可以看看。

　　正是這個誤解的存在，使得很多開發(fā)者看到了設計模式所帶給程序結構的靈活性，從而在進行代碼重構時就把結構的靈活性作為一個最重要的目標。最終導致了程序結構的過分靈活性，損傷了軟件的質量。

　　但是，設計模式確實能夠改善我們的程序結構，面向對象大師Martin Fowler的經(jīng)典著作《Refactoring Improving the Design of Existing Code》一書中就有很多的使用設計模式進行重構的例子。難道僅僅是因為設計模式能夠帶來足夠的靈活性嗎？顯然不是！主要是因為這些設計模式更能夠展示設計者的設計意圖，更加便于理解！

　　很多面向對象專家和模式研究專家對重構的動機進行了研究，發(fā)現(xiàn)對于一個好的重構過程來說，重構的結果到底是不是一個設計模式是不重要的。它們的最終動機都是：減少或者消除冗余代碼，簡化設計最終達到展示真正的設計意圖，更加便于交流。

　　Martin Fowler的《Refactoring》一書的第一章有一個關于影碟出租的例子，詳細的展示了重構的過程以及每一步的動機，很好的說明了上面的問題。

　　5、再談設計模式的動機
　　本系列文章的第一篇中談論設計模式本身的意圖、動機的重要性。這里我想再結合上面的內容重新認識一下這個問題�，F(xiàn)在我們有兩個動機存在，設計模式本身的動機以及我們要重構來改善我們的程序結構的動機（可能是要重構到一個設計模式）。這兩個動機其實是沒有很大的關系的。

　　設計模式本身的動機往往是領域無關的，但是我們重構到設計模式的動機卻往往是領域相關的。因為我們重構的主要目標是要達到能夠很好的展示我們的設計意圖，而這些設計意圖往往和問題領域的上下文關系密切。

　　比如：Factory Method設計模式的意圖是定義一個創(chuàng)建對象的接口，讓子類來確定到底實例化哪個類，F(xiàn)actory Method方法使得一個類的實例化時機延遲到子類中。但是我們在重構的過程中何時決定使用Factory Method設計模式呢？基本上是因為一個類的構造方式有多種，每一種都有不同的含義，但是構造函數(shù)的名字是唯一的，通過同樣的構造函數(shù)名，賦予不同的參數(shù)的方法來實例化對象的方式，使得使用者很難理解這個構造函數(shù)的真正含義。所以通過使用Factory Method設計模式，定義不同的用于展示具體意圖的函數(shù)名稱來實例化對象，就更加能夠展示使用者的意圖。另外，該模式還簡化了該類的構造方式，封裝了該類的實例化細節(jié)。

　　參考文獻〔2〕中有很多這方面的實例，大家可以下載下來閱讀一下，相信會有更大的收獲。

　　6、結論
　　本文結合設計模式探討了在進行程序結構改善的過程中，容易造成的誤解：即過分的關注程序結構的靈活性。這樣做很容易從是否能夠給設計帶來靈活性的角度來進行程序結構的重構，最終可能造成系統(tǒng)的復雜、混亂、不易理解、難以維護，從而導致項目失敗。其實一個好的程序結構根本不在于其中使用了多少設計模式、多么具有彈性，主要在于該結構是否能夠非常清晰的展現(xiàn)設計者的意圖（可以參考參考文獻〔1〕）。由于在很多情況下，通過引入設計模式可以很好的做到這一點，所以設計模式往往會成為重構的目標，但是有一點要記�。翰灰�過早的引入設計模式，要讓它在重構的過程中自然浮現(xiàn)出來。

　　參考資料
　　[1] To Be Explicit，Martin Fowler, IEEE Software Vol.18 No.6
　　[2] Refactoring To Patterns, Joshua Kerievsky, industriallogic.com
　　[3] Is Design Dead, Martin Fowler, www.martinfowler.com