How to Use Design Patterns
[URL=http://www.artima.com/lejava/articles/gammadp.html]http://www.artima.com/lejava/articles/gammadp.html[/URL]
如何使用設計模式
與Erich Gamma的一次談話，第一部分
Bill Venners
May 23, 2005
翻譯：http://blog.csdn.net/lxwde

摘要
    在開發者中間，設計模式是思考設計問題的很受歡迎的一種方法，但是怎樣才是思考設計模式的正確方法呢？在這次采訪中，Erich Gamma（里程碑式的書籍《設計模式》的作者之一）和Bill Venners談論了關于如何思考和使用設計模式的正確方法。

    Erich Gamma是在1995年作為暢銷書籍《設計模式：可復用面向對象軟件的基礎》(Addison-Wesley, 1995) [see Resources]的合著者而躍上軟件業界舞臺的。這項具有里程碑意義的工作，經常被援引為四人幫（GoF）的書，該書針對通常的設計問題分類整理出了23種特定的解決方案。1998年，他和Kent Beck組成團隊開發JUnit[see Resources]，這成為Java社區事實上的單元測試工具。Gamma現在是IBM的一名杰出工程師，他在位于瑞士蘇黎世的IBM Object Technology International（OTI）實驗室工作。他擔任Eclipse社區的領導工作，負責Eclipse平臺[see Resources]上與Java開發相關的事務。

    2004年10月27號，Bill Venners 在加拿大溫哥華舉行的OOPSLA會議上遇到了Erich Gamma。在這次采訪中（這次采訪的內容將分多次在Artima Developer的Leading-Edge Java頻道刊登出來），Gamma講述了軟件設計中深層次的東西。在這個系列的第一篇文章中，Gamma給出了他對于如何正確思考和使用設計模式的看法，并且描述了不同模式庫之間的差異，比如GoF和Alexandrian的模式語言。

設計模式的真正價值

Bill Venners: Bruce Eckel 和我在教授設計模式課程，我們發現大家非常想了解四人幫（GoF）總結的那些模式。模式讓講座買的更火。圍繞設計模式有很多關于市場的噱頭可做。

Erich Gamma: 現在仍然這樣么，已經過了10年了?

Bill Venners: 是的。大家想了解設計模式，而且我懷疑這很大程度上是因為“模式”仍然是一個時髦的詞匯。我想繞過那些噱頭問問你人們到底該如何對待設計模式。他們對于設計模式的態度應該是個什么樣子？人們如何才能使用模式把工作做的更出色？它真正的價值到底是什么？ 

Erich Gamma: 我想模式作為一個整體可以幫助人們學習面向對象的思想：你如何才能用好多態（polymorphism），設計好組合（composition）和委托（delegation），平衡職責，并且提供可插拔的行為（pluggable behavior）。相對于把對象應用到繪畫圖形（graphical shape）的例子（有一個關于圖形的類層次和一些多態的draw方法），模式要更深入一些。當你理解了模式以后，你就真正學會了多態。所以通常來說模式對于學習OO和設計是有好處的。

    在此基礎上，每個單獨的模式都有不同的特性可以在某些地方為你提供幫助，比如你需要更大的靈活性或者需要封裝一個抽象或者需要讓你的代碼耦合的更松散的時候。這在大系統里確實是個大問題。如何保持你的分層？如何避免對向上的調用（up calls）或者循環依賴？GoF模式幾乎沒有提供什么工具幫助你解決這些問題。他們提供的幫助不是給你一個完美的解決方案而是通過解釋如何權衡利弊。盡管模式是從具體應用中抽象出來的，他們仍然提供給你關于實現的有價值的線索。以我的觀點來看，正是因為模式都是可實現的才使它們如此有價值。

    模式都是從牛人的經驗里提取出來的。它們使你可以重復別人做過的成功的設計。這樣一來你就可以站在牛人的肩膀上，用不著重新發明輪子了。但是，因為模式可以有許多實現上的變體，所以你仍然需要保持清醒的頭腦。最后，由于模式提供給你用于設計的積木塊的名稱，所以它們也提供給你用于描述和討論特定設計的一個詞匯表。

    另一個問題是我們該如何教授模式。我并不確切知道你該如何做，但是我想你不該做的一件事是用一個類來列舉23種模式。這么做并不能帶來任何好處。你必須得體會到一個有問題的設計所帶來的痛苦。我猜想只有感受到這種設計上的痛苦你才會認識到某個模式的重要性。

Bill Venners: 什么痛苦？

Erich Gamma: 比如說意識到你的設計不夠靈活，一個小小的改動會波及到整個系統，你必須復制代碼，或者代碼變的越來越復雜。如果你在這樣一個棘手的情況下應用某個模式，有可能會使這種痛苦消失并且后來還很舒服。當你意識到，哦，實際上這個模式，工廠模式（factory）或者策略模式（strategy），是解決我的問題的方法，你會有一種恍然大悟的感覺。我想這才是教授設計模式真正有趣的方法。

    我一開始教授設計模式的時候是非常單調乏味的，因為我只是列舉那些模式。我發現試著通過實際例子激發如何應用模式會有趣的多。換句話說，你確實需要在現實背景中展示一個實際的例子——炮制出來的例子不管用。在OOPSLA的會議上我收到一本《Heads First Design Patterns》[see Resources]。這是一本很棒的書，不僅僅是因為它讀起來很有趣，而且還因為它們能夠通過一種小說似的高度可視化的方法來傳達設計模式的本質。
Bill Venners: 那么，是不是說模式的價值就是，當我在現實世界中感受到某種特定的痛苦，我可以求助于某個已知的解決方案？

Erich Gamma: 毫無疑問，這是我推薦大家使用模式的方法。不要一開始就馬上把模式套進某個設計，而是當你一邊深入并且對問題理解更多的時候才使用它們。因為這個原因，我更愿意在犯錯誤之后使用模式，朝著模式的方向重構（refactoring to patterns）。在模式剛剛開始變的更加流行的時候，我在一個新聞組里看到一條評論說，有人聲稱他們要在一個特定的程序里嘗試使用所有23種GoF模式。他們說他們失敗了，因為只能用到20種。他們希望客戶會再叫他們回去，這樣他們可能就可以把剩下3種也加進去。

    試圖使用所有的模式是不好的做法，因為你最終得到的是人工臆想出來的設計——過于深思熟慮的設計，有靈活性但卻沒有人需要用到。現今的軟件都太復雜了。我們沒功夫推測它額外要做的事情。我們需要真正聚焦在它必需做的事情上。這就是為什么我喜歡朝著模式的方向重構。人們應該學會在碰到某個特定類型的問題或者代碼味道（現在大家都這么說）的時候，去他們的模式工具箱尋找一個解決方案。

Bill Venners: 真滑稽，因為我的第二個問題是，我發現人們經常覺得使用模式最多的設計是最好的設計。在我們講授設計的講座上，我讓參與者做一個設計項目，在講座結束的時候大家要把自己的設計講給別人聽。幾乎毫無例外，那些講述的人總是想炫耀他們在自己的設計里使用了多少模式，盡管我試圖告訴他們目標是要一個干凈，易于理解的API，而不是要他們贏得一個“看誰模式用的多”的比賽。我剛剛聽你說了同樣的事情，也就是說，這不是思考模式的正確方法。如果這種方法不對，那么在設計里使用模式的正當理由是什么呢？

Erich Gamma: 很多模式是關于擴展性和重用性的。當你確實需要擴展性的時候，模式提供給你某種方法讓你實現它，而且這很酷。但是當不需要它的時候，你應該讓你的設計保持簡單并且不要添加不需要的抽象層。我們Eclipse的一條原則就是，我們只在要緊的地方需要擴展性。實際上，如果你對我們在Eclipse中是如何使用模式感興趣的話，我曾經嘗試把模式的應用提取出來放到《the Contributing to Eclipse》[see Resources]一書中的一個章節里。在這一章里，我使用設計模式解釋了Eclipse架構的一些片斷。

Bill Venners: 說到擴展性，您這是什么意思？

Erich Gamma: 就是說你可以定制行為，而不用觸及已經存在的代碼——這是OO里面很經典的一個主題。你可以重用針對特定問題調整過的某些東西。

被設計模式所包圍的核心抽象

Bill Venners: 在您與Kent Beck合寫的一篇叫做“JUnit: A Cook's Tour” [see Resources]的文章中，你引領讀者沿著JUnit的設計路線，如您自己所寫的，“從零開始一個接一個的應用模式，直到得到系統的架構”。我想這種方法可能是受了Christopher Alexander的啟發，他在建筑學上有關模式的工作激發了軟件模式的運動。您覺得把某個模式放置在另外一個模式的層次之上，直到最后完成設計，這是一種有效的設計方法么？

Erich Gamma: “The Cook's tour”那篇文章多少有點人為炮制的痕跡。我們修整了JUnit原先的設計。然而，我們并不是以這么一種模式驅動的方法開發JUnit的，事實上，我們是嚴格按照測試驅動的方法來開發的。對于JUnit來說，它確實有一個針對測試的核心抽象，圍繞著這個核心抽象你會看到其它幾個設計要點顯現出來，這幾個設計要點又依次被模式實例具體化。這些東西是你在成熟設計里經常能看到的。有一些關鍵抽象，你會經常把他們看作一個設計的中心，圍繞這些關鍵抽象你希望完成各種各樣的事情。于是你就會看到模式從這樣一個中心不斷長出來。但是我不會把這個作為評判（軟件）質量的標準。

Bill Venners: 這就是當您說“模式密度（pattern density）”的時候所指的東西么？

Erich Gamma: 是的，確實如此，模式圍繞著某些中心抽象浮現出來的。

Bill Venners: 您說過測試用例（TestCase）是JUnit的核心抽象。

Erich Gamma: 準確的說是由測試用例實現的測試接口，但是我們確實是從測試用例開始并且以它為基礎擴展的。

Bill Venners: 那么，您能給密度（density）下個定義么？是指圍繞它的模式的個數么？您說過“JUnit Cook's Tour”那篇文章多少有點人為炮制的意思。

Erich Gamma: 炮制在某種意義上是說“the cooks tour”那篇文章是當你去掉在我們的測試驅動開發過程中所產生的所有測試活動所剩下的東西。所以它是一個高度壓縮的陳述。密度從圍繞Test固定下來了的那些模式中顯現出來。

    設計JUnit的時候，我們不是僅僅把模式捆綁在一起。我們用模式驅動來做，從一個我們想要成功完成的測試開始，一旦它通過，我們會仔細看看如何能夠改善那些代碼。用測試驅動的方法開發一個測試框架并不是說沒有沒有它的挑戰性，但是一旦基本的東西跑起來以后，會變得出奇的順利。你知道，Kent和我在開發JUnit的時候對模式非常熟練。所以很自然，我們會說諸如，“嘿，那是一個嵌套模式（composite）。” Composite是JUnit用到的一個模式。我們還使用了模板方法（template method）。這是很基本的一個模式。我們用過Command模式。這當然是主要的一個。我們從測試開始并且說，“哦，這是一個command。哦，這是一個template。” 因為我們對模式都很熟練，我們的交談進行的非常的快，這使我們可以以高速度完成一個設計。

    這實際上很好的說明了模式是如何為我們提供設計語匯的。當你看一個UML圖的時候，情況也是類似的，你會看到方形和箭頭，但他們沒有真正告訴你在這些關系后面的含義。但是一旦你了解到那個模式，它就為你解釋了這些關系是到底是干嗎的。如果它是個觀察者模式（observer），那在兩個類之間為什么會有一個連線就很清楚了。那是因為一個家伙要觀察另外一個家伙。你確切知道所發生的是什么。我猜這就是關鍵點。模式給了我們一種用于討論設計的語言。實際上，JUnit之旅并沒有結束，Kent和我現在還在忙于JUnit 4。我們仍然通過測試驅動的方法不斷完善JUnit。我們有個想法就是要降低上手的門檻。為了達到這個目的，我們正在采用J2SE 5的中的某些功能，比如annotations，把JUnit弄得更加易于使用。

模式語言

Bill Venners: 就Alexandrian的本意來說，什么是模式語言?

Erich Gamma: Alexander有一個非常遠大的目標， 他想創造出可以提升生活質量的建筑。為了完成這個目標，Alexander發展出了模式語言。這是一系列互相構建于彼此之上的模式。模式語言指導設計者把單個的模式應用到整個設計。我們開始弄設計模式的時候并沒有那么遠大的理想。我們使用一種以微觀架構（micro-architectures）為基礎的，更傾向于自底向上的方法。

Bill Venners: 您說的自底向上是什么意思？

Erich Gamma: 讓我往回一點說說我是如何進入模式領域的。我想這可以回答你的問題。我曾經和Andre Weinand一道開發ET++，這是一個龐大的C++類庫和框架。當我深入思考ET++的時候，一個成熟的框架顯現了出來，它包括一些反復出現的設計結構的，這些設計結構能夠給你很多特性，諸如擴展性，解藕，還有很重要的是——優雅。這些結構可以被認為是為整個系統架構做出貢獻的微觀架構。最后我在自己的論文里以書面形式整理了十幾個這種微觀架構。這種針對模式的方法有別于模式語言：它并不是以自頂向下的方法弄出一系列相互交織的模式，微觀架構更傾向于是相互獨立而最終又以自底向上的方式相互關聯的模式。模式語言為你提供的知道貫穿整個設計，而我們有的只是這些碎片式的，零星的工程學知識。我承認，這種做法目標不夠遠大，但是它仍然很重要并且很有用。
Bill Venners: 模式語言是不是就像持有一個上下文無關的語法，你可以用它來產生一大堆程序？

Erich Gamma:從抽象的層次上來說，它們之間有某些相似性。用一個語法可以定義一大堆程序，同樣的，模式語言可以產生一堆解決方案。Christopher Alexander是這么描述的，他說他的模式描述了某種解決方案，所以它就可以被多次應用而沒必要每次都保持不變。但是我認為到這個層次共同性就消失了。

Bill Venners: 說到產生，他是什么意思？如果我有一個上下文無關的語法，它并不能產生程序。我仍然的把它們寫出來。

Erich Gamma: 你仍然需要做決定，但是模式語言提供給你更多的指導而且它有一定的流程。比方說你想設計一個自己住著舒服的房間。他說，先在兩邊都放上燈。好，現在你在兩邊都放上了燈，下一步做什么？你如何安放窗戶？針對這個問題會有其它的模式描述一個解決方案。他基本上指導你布置整個空間。這種聯系正是一個模式庫（比如我們在GoF那本書里描述的那些）和模式語言的區別所在。我們發現，這些微觀架構實際上也不是孤島。它們之間也發生關系。我們在那本書的封面的內頁畫出了它們之間的關系，而且這是Alexander的擁護者認為我們這本書唯一有價值的地方。

Bill Venners: 聽起來幾乎像是一個設計的方法論。你沿著這條路，一步步做下去，最后得到可以坐在里面的，漂亮而又舒服的房間。

Erich Gamma: 是的，當你遵循Alexander的模式方法的時候，你就是在按照一定順序使用這些模式。我們并沒有限制一個特定的順序。如果你有問題，我們有相應的解決方案，但是我們沒有下個步驟。我們不會給你暗示說下一步該干什么。就這種意義來說，Alexander的方法是更徹底的。JUnit采用了一點這種模式語言的方法，因為它可以幫你寫一個測試用例。在JUnit的文檔里，Kent和我寫了一個關于如何實現一個測試的迷你型的模式語言。以一個測試作為開始，接下來你希望提取出公共的初始化代碼，然后你會希望給測試分組，等等。

下周

    5月30號，星期一，請您回來看與Erich Gamma這次談話的下一部分。如果你想收到Artima.com上新文章每周簡報的電子郵件，請訂閱 Artima Newsletter。

反饋

    對本文中討論的設計模式話題有自己的觀點么？那么請到文章論壇里討論這個話題, The True Utility of Design Patterns.


資源

Erich Gamma是《設計模式：可復用面向對象軟件的基礎》的合著者之一，可以在Amazon.com上找到這本書                                  ：
http://www.amazon.com/exec/obidos/ASIN/0201633612/

Erich Gamma 是JUnit的作者之一，JUnit是事實上的Java單元測試標準工具：
http://www.junit.org/index.htm

Erich Gamma 領導Eclipse平臺上與Java開發相關的事務：
http://www.eclipse.org/

《Head First Design Patterns》, 作者是 Elisabeth Freeman, Eric Freeman, Bert Bates, 和 Kathy Sierra, 這本書可以在Amazon.com上找到：
http://www.amazon.com/exec/obidos/ASIN/0596007124/

你可以從Arima的樣章書庫（chapters library）下載《Head First Design Patterns》的一個免費章節                                                     ：
http://www.artima.com/chapters/book.jsp?num=90281

《Contributing to Eclipse: Principles, Patterns, and Plug-Ins》, 作者是 Erich Gamma 和 Kent Beck, 這本書可以在Amazon.com上找到：http://www.amazon.com/exec/obidos/ASIN/0321205758/

JUnit: A Cook's Tour, 這是Erich Gamma 和Kent Beck寫的一篇文章， 這篇文章引領你沿著JUnit的設計路線，“從零開始一個接一個的應用模式，直到得到系統的架構”
http://junit.sourceforge.net/doc/cookstour/cookstour.htm

關于作者

    Bill Venners 是Artima軟件公司的主席兼Artima Developer的主編。他是《Inside the Java Virtual Machine》一書的作者，該書從面向程序員的角度講述了Java平臺的架構和內幕。他在JavaWorld雜志上廣受歡迎的專欄覆蓋了Java內幕，面向對象設計，以及Jini。從Jini啟動以來，Bill就活躍在這個社區。他領導Jini社區的ServiceUI項目，這個ServiceUI API成為連接用戶接口和Jini服務之間既成事實的標準方法。Bill還被選為Jini社區最初的技術監管委員會（TOC）的一員，他擔任這個職務期間幫助定義了社區的管理流程。