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

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

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

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

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

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

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

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

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

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

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

　　設(shè)計模式一般會成為重構(gòu)的目標(biāo)，但是為什么要這樣做？我們一定要重構(gòu)到一個設(shè)計模式嗎？怎樣的程序結(jié)構(gòu)才是好的呢？

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

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

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

　　很多面向?qū)ο髮＜液湍Ｊ窖芯繉＜覍χ貥?gòu)的動機進行了研究，發(fā)現(xiàn)對于一個好的重構(gòu)過程來說，重構(gòu)的結(jié)果到底是不是一個設(shè)計模式是不重要的。它們的最終動機都是：減少或者消除冗余代碼，簡化設(shè)計最終達到展示真正的設(shè)計意圖，更加便于交流。

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

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

　　設(shè)計模式本身的動機往往是領(lǐng)域無關(guān)的，但是我們重構(gòu)到設(shè)計模式的動機卻往往是領(lǐng)域相關(guān)的。因為我們重構(gòu)的主要目標(biāo)是要達到能夠很好的展示我們的設(shè)計意圖，而這些設(shè)計意圖往往和問題領(lǐng)域的上下文關(guān)系密切。

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

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

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