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

1、介紹

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

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

2、過分設計的危害

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

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

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

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

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

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

3、軟件開發的節奏

現在在軟件工程領域很活躍的一個組織是：靈敏社團，他們提出了一系列的靈敏方法（XP就是其中很聞名的一種）。在靈敏方法中制定了一系列的策略、實踐來擁抱需求的變化。其目標是：使軟件以規范的節奏進展，最終保質、按時交付軟件產品。現在已有很多使用這種方法成功的商業案例。

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

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

4、要害是要展現設計意圖

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

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

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

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

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

5、再談設計模式的動機

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