引言
在軟件開發過程中，一個系統成敗的關鍵就是在于其設計，如果系統設計的很好，那么在后續開發中就能少走彎路，并且在后續的系統維護中，能夠簡單、輕松，但如果系統設計中就出現了問題，那么這個系統的開發必然是痛苦的，編程人員的不停抱怨，維護人員的痛苦掙扎，最終導致系統的報廢，沒有人愿意再去關注它。
因此，人們非常希望能夠在新的軟件開發過程中使用那些在軟件系統設計、開發過程中長期積累的很多好的、有價值的經驗，來提高新系統的開發效率，保證新系統能夠穩定、安全、易于維護。
所以，如何將這些有價值的經驗記錄下來，能夠很好的交流、傳遞就顯得非常重要。對這些直接的、原始的經驗，采用面向對象的方法進行抽象，提煉出很多的模式，這些模式很清晰的說明了它們所表達的關聯、問題和解決方式之間的關系。而這些在軟件設計上積累、抽象出來的模式，我們稱之為設計模式。
設計模式的概念
簡單地說，模式是一個出現在世界上的實物，同時也是一條規則，告訴你應該如何創建一個實物、應該在何時創建。它既是過程，也是實物；既是對當前實物的描述，也是對創建實物的過程的描述。我們需要這樣一種語言：它讓我們高效地交流、討論那些常見的、重復出現的設計概念，并在這些概念上建立起我們的系統。不要僅僅把模式當作解決方案，而要把它們當作設計的詞匯，這些詞匯可以根據一定的規則組合起來形成句子（也就是系統設計）。
C. Alexander描述：“每個模式是一個有三個部分的規則，它表達一定的關聯、一個問題和一個解決方式之間的關系�！�
設計模式可以使人們更加方便的復用成功的設計和體系結構。將已證實的技術表述成設計模式也會使新系統的開發者更加容易理解其設計思路。設計模式幫助你做出有利于系統間潛在聯系的說明規范，設計模式甚至能夠提高已有系統的文檔管理和系統維護的有效性。簡而言之，設計模式可以幫助設計者更快更好的完成系統設計。
設計模式的分類
在《設計模式》書中共給出了二十三個模式。這二十三又根據其表現不同可分成了幾類。各個模式是在不同場景下，不同問題的解決方案。
創建型模式
創建型模式抽象了實例化過程。它們幫助一個系統獨立于如何創建、組合和表示它的那些對象。一個類創建型模式使用繼承改變被實例化的類，而一個對象創建型模式將實例化委托給另一個對象。
隨著系統演化得越來越依賴于對象復合而不是類繼承，創建型模式變得更為重要。當這種情況發生時，重心從對一組固定行為得硬編碼轉移為定義一個較小的基本行為集，這些行為可以被組合成任意數目的更為復雜的行為。這樣創建有特定行為的對象要求的不僅僅是實例化一個類。
創建型模式中有兩個不斷出現的主旋律。第一，它們都將關于該系統使用哪些具體的類的信息封裝起來。第二，它們隱藏了這些類的實例是如何被創建和放在一起的。整個系統關于這些對象所知道的是由抽象類所定義的接口。因此，創建型模式在什么被創建，誰創建它，它是怎樣被創建的，以及何時創建這些方面給予你很大的靈活性。它們允許你使用結構和功能差別很大的“產品”對象配置一個系統。配置可以是靜態的（即在編譯時指定），也可以是動態的（在運行時）。
結構型模式
結構型模式涉及到如何組合類和對象以獲得更大的結構。結構型模式采用繼承機制來組合接口或實現。一個簡單的例子是采用多重繼承方法將兩個以上的類組合成一個類，結果這個類包含了所有父類的性質。這一模式尤其有助于多個獨立開發的類庫協同工作。
結構型對象模式不是對接口和實現進行組合，而是描述了如何對一些對象進行組合，從而實現新功能的一些方法。因為可以在運行時刻改變對象組合關系，所以對象組合方式具有更大的靈活性，而這種機制用靜態類組合是不可能實現的。
行為模式
行為模式涉及到算法和對象間職責的分配。行為模式不僅描述對象或類的模式，還描述它們之間的通信模式。這些模式刻畫了在運行時難以跟蹤的復雜的控制流。它們將你的注意力從控制流轉移到對象間的聯系方式上來。
行為類模式使用繼承機制在類間分派行為。本章包括兩個這樣的模式。
行為對象模式使用對象復合而不是繼承。一些行為對象模式描述了一組對等的對象怎樣相互協作以完成其中任一個對象都無法單獨完成的任務。這里一個重要的問題是對等的對象如何了解對方。對等對象可以保持顯式的對對方的引用，但那會增加它們的耦合度。在極端的情況下，每一個對象都要了解所有其他的對象。
從設計模式中得到的收獲
設計模式是系統地命名、解釋和評價了面向對象系統中一個重要的和重復出現的設計，其目標是將設計經驗以人們能夠有效利用的形式記錄下來。設計模式使人們可以更加簡單方便地復用成功地設計和體系結構。將已證實的技術表述成設計模式也會使新系統開發者更加容易理解其設計思路。設計模式幫助你做出有利于系統復用的選擇，避免設計損害了系統復用性。通過提供一個顯示類和對象作用關系以及它們之間潛在聯系的說明規范，設計模式甚至能夠提高已有系統的文檔管理和系統維護的有效性。簡而言之，設計模式可以幫助設計者更快更好地完成系統設計。
模式的絕大多數好處都來自于原封不動的使用，也就是說，沒有任何形式的外部支持，這帶來了四大好處：
1. 它們記錄了專家的經驗，并且讓非專家也能理解。
2. 它們的名稱構成了一份詞匯表，幫助開發者更好的交流。
3. 它們幫助人們更快的理解一個系統，只要這個系統是用模式的方式描述的。
4. 它們使系統的重組變得更容易，不管原來的系統是否以模式的方式設計的。
第一項顯然是模式最大的好處，但第二項也同樣重要，試想在一個開發項目的過程中，包括口頭的和電子的，有多少字節的信息在開發者之間流動，由于有如此之大的信息交流量，所以效率上任何微小的提升都能大量節約時間。在這個意義上，模式拓寬了人們交流的帶寬。對于第三、四條的評價，也越來越顯著，特別是在項目越來越大、軟件生存周期越來越長的今天。
當然，至少在短期內，模式主要存在于大腦中，而不存在于工具中。如果有了方法學或自動化工具的支持，應該還有其他的收益。
應用設計模式時存在的問題
顯然，設計模式為我們的軟件開發提供了非常有價值的經驗和方法。同時，也為我們提供了一個有價值的思路，就是將我們自己的經驗總結成模式來交流。但與此同時，對于模式的理解和使用，也存在著許多問題。
對模式的誤解主要有三類：首先是對于“ 模式是什么” 的誤解， 其次是對于“ 模式可以做什么” 的誤解， 最后是對于支持模式的人群的誤解。
模式是什么？如果對模式的概念簡化，就是“模式是某種場景下某個問題的解決方案”，但這個說法是不完全的，因為忽略的模式的幾個重要因素：
1. 可重復性：解決方案應該對應于外部的場景，這個場景是會重復發生的。
2. 可傳授性：一個解決方案應該可以移植到問題的不同情況上（ 絕大多數模式的可傳授性都建立在“約束”和“效果”的基礎上）。
3. 準確的命名：用來表示這個模式的名稱，因為模式既是一個事物， 也是對類似事物的描述。
可重復性定義了這個場景是會多次出現的，因此我們需要多次面對，并解決同樣的問題�？蓚魇谛詣t定義這個經驗是有必要的傳授的。而準確的命名則是模式描述準確性及其交流時的重要保證，雖然，術語的定義很可能是白費力氣，因為一個定義可能對一個人（比如程序員）有意義，但是對另一個人（比如只能看到書面材料的項目主管）卻毫無意義。所以，任何對模式要素的規定，除了必須包括問題、解決方案和場景之外，都必須提及可重復性、可傳授性和名稱。
那么模式可以做什么？“模式可以保證軟件的復用性、更高的生產力……”
道理很簡單，模式什么都不保證。它們甚至有可能無法給你帶來利益。在創造新事物的過程中，模式無法取代人的位置。它們只是帶來一種希望，有可能讓一個缺乏經驗的、甚至是未入門的，但是有能力、有創造性的人盡快獲得設計的能力。
人們經常說：好的模式會讓讀者有“��！”的回應。實際上，只有當模式恰好撥動了讀者的某一根心弦時，他們才會有這樣的反應。如果沒有，模式就只像森林里普通的一棵樹。因此，什么是好的模式？不管它寫得有多好，如果不能引起讀者的共鳴，它又怎能算是好的模式？模式只是開發者的工具箱中的另一件工具，對模式寄以過高的期望只會適得其反。準備充分，然后做最壞的打算——這就是防止受騙、消除對抗最好的方法。
“模式可以‘生成’整個軟件體系”
每過一段時間，模式論壇上就會討論一次模式的生成能力。按照我的理解，“生成能力”是指模式創建最終行為的能力。很多人認為，模式可以幫助讀者解決模式本身沒有明確提出的問題。我讀過的一些書里也有同樣的觀點。
對于我來說，“生成能力”的關鍵是模式的可傳授性——約束及其解決，或者對于效果的討論。在你定義、精煉一個體系結構時，這些觀察是特別有用的。但是模式本身并不制造任何東西——任何東西都是由人來制造的。而且，模式不可能覆蓋體系結構的每個方面。給我任何一個有實際價值的設計，我都能找出其中模式沒有涉及的設計問題。也許這些問題不常見、不具可重復性，或者只是還沒有以模式的形式記錄下來。不管怎樣，你都必須負責填補模式之間的空白——用你自己的創造性。
“模式是針對（面向對象）設計或實現的”
另一個極端則是過分的限制，就象這個誤解。坦白說，任何人都完全可能相信它，我不會有絲毫驚訝。無數的人問過我這個問題，所以它也進入了“十大誤解”之列。如果你覺得這種觀點實在天真幼稚，跳過這一部分吧。
如果模式不能記述專家的經驗，那它們就什么都不是。對于模式的作者來說，任何形式的專家經驗
都是可記載的。當然，在面向對象軟件設計中有值得記載的經驗，但是在非面向對象設計和分析、維護、測試、文檔、組織結構……這些方面也同樣有值得記載的經驗�，F在，不同領域中的模式開始浮出水面。
至少已經有兩本關于分析模式的書[Fowler97, Hay96]，并且每次PLoP 大會都會收到新的模式類型。（特別有趣的是1996 年的PLoP 大會甚至關注了音樂作曲的模式�。�
和大多數的誤解一樣，這個誤解也是有原因的�？纯慈藗冇脕砻枋瞿Ｊ降母袷�，有兩種基本的風格：
描述高層結構的GoF 風格（用于《設計模式》中）；接近文學的Christopher Alexander 風格——敘述性的，盡量少的結構圖。由于已經用模式描述了面向對象設計之外的東西，所以我現在認識到GoF 風格
造成的偏差。對于我研究過的某些領域的專家經驗，這種風格根本無法描述。為什么結構圖看上去總是讓人聯想到C++？對于音樂作曲的模式，“實現”應該是什么？“協作”部分真的有意義嗎？
很明顯，一種格式不能適應所有的需求。比較具有普遍意義的是模式的概念：模式是記載并傳達專家經驗的工具——不論是哪個領域的專家經驗。
對于支持模式的人群的誤解
“模式社群是精英的小圈子”
我很想知道這種觀念到底是從哪里來的。如果說模式社群的人們有什么引人注目的地方，那就是他們之間巨大的差異。從PLoP 大會的與會者名單就能看出，人們來自世界各地，有大公司的也有小公司的，有分析員、設計者和實現者，有學生也有教授，有大名鼎鼎的作者也有初出茅廬的菜鳥。更讓我驚訝的是，竟然有不少與會者都不是計算機科學工作者！這個社群仍然在不停變化，每年的與會者名單都與前一年不同。
如果將模式社群的背景公開出來，別人也許會覺得奇怪：很少有學院派人士。實際上，絕大多數PLoP的與會者都是實踐者。軟件模式早期的推崇者，包括Kent Beck、Peter Coad 和Ward Cunningham，都沒有學院背景。GoF 中只有一個人（Ralph）是學院派，而且他也是我所認識的最實際的學院派。很明顯，模式社群從根本上反對任何可能的宗派主義和精英論。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
