從面向對象到模式再到真正的面向對象


Alan Shalloway 著 透明 譯

（譯序：
本文摘自Design Patterns Explained: A New Perspective on Object-Oriented Design一書的前言部分。通過本文，讀者可以大概了解學習設計模式的過程和效果。同時，作者謙虛謹慎的態度也是非常值得我們中國軟件開發者學習的。
譯者保留本文一切權利。如果需要將本文用于非營利性目的，請E-mail通知我：gigix@263.net）

這本書的很多地方都復述了我自己學習設計模式的經驗。在學習設計模式之前，我認為自己理所當然是面向對象分析和設計的專家。我曾經為各種行業的客戶做過一些還算給人深刻印象的設計和實現。我會使用C++并且已經開始學習JAVA。我的代碼中的對象格式優美封裝緊密。我可以在繼承體系中設計優秀的數據抽象。我想我已經懂得面向對象了。

現在回頭看看，我發現那時其實我還根本不知道面向對象設計的全部能力，盡管我一直按照專家建議的方式來做。直到我開始學習設計模式，我的面向對象設計能力才得到了擴展和深化。學習設計模式使我成為了一個更好的設計者，甚至是我還沒有直接使用那些模式的時候。

我從1996年開始學習設計模式。當時我正在西北部一家大型航天公司擔任C++/面向對象設計顧問。有幾個人勸說我領導一個設計模式學習組。正是在那里我遇到了本書的另一個作者Jim Scott。在那個學習組中發生了幾件有趣的事情。首先，我開始對設計模式著迷。我可以把自己的設計和其他更有經驗的人的設計相比較，我愛上了這種感覺。另一方面，我發現我并沒有完全做到"對接口做設計"，也沒有隨時注意"一個對象是否可以在不知道另外對象的類型的情況下使用另外對象"。同時我注意到，那些面向對象的初學者--通常他們被認為過早開始學習設計模式--從這個學習組得到的收益與那些面向對象的專家不相上下。設計模式向學習者展現出優秀的面向對象設計實例并闡述基本的面向對象設計原則，而這些使學習者的設計更快地成熟起來。在整個學習進程結束之后，我確信：設計模式，這是面向對象設計被發明之后軟件設計中最好的東西。

但是，看看那個時候我自己的工作，我發現我根本還沒有在自己寫的代碼中結合任何一個設計模式。

當時我只是認為自己還沒有學到足夠的設計模式，還需要學習更多。那時候，我只知道六個設計模式。然后我可以說是得到了頓悟。我在一個項目中擔任面向對象設計顧問，并需要為這個項目創建一個高層設計。這個項目的領導人極其聰明，但在面向對象設計領域，他可以說是一個新手。

這個問題本身并不困難，但需要非常注意確保代碼容易維護。按照慣例，在看過問題兩分鐘之后，我便有了一個設計--采用了我常用的數據抽象的途徑。很不幸的是，很顯然這不會是一個好的設計。簡單的數據抽象已經讓我嘗到過失敗的滋味。我必須找到一些更好的設計思路。

兩個小時過去了。在使用了我所知道的所有設計技術之后，情況仍然沒有好轉。我的設計基本上都還是和從前一樣。而最讓我感覺受挫的是，我知道一定有一個更好的設計，但我就是找不到它。更具諷刺意義的是，我甚至還知道四個設計模式就"生活"在我的問題中，但我看不出應該如何使用它們。在這里，我，一個被認為是面向對象設計專家的人，被一個簡單的問題困住了！

我實在覺得很受挫，于是我停了下來，開始繞墻行走以清醒頭腦，并告訴自己：至少10分鐘里我不再想這個問題。呵呵，30秒之后，我又開始想它了！但我獲得了一種領悟并完全改變了我對設計模式的看法：設計模式無法作為獨立的條款使用；我應該把設計模式放在一起使用。

模式是應該被結合在一起來共同解決一個問題的。

以前我曾經聽到過這句話，但那時我并沒有真正理解它。因為軟件開發中的模式往往被介紹為"設計模式"，所以我總是在"模式最主要的貢獻是在設計階段"的假設下努力。我的想法是：在設計世界里，模式就好象是類之間優美的聯系。然后，我閱讀了Christopher Alexander那本令人驚訝的書--The Timeless Way of Building。我學到了：模式存在在所有的階段--分析、設計以及實現--之中。Alexander在書中討論了如何使用模式來幫助理解（乃至描述）問題領域，而不是僅僅在理解了問題領域后使用模式來創建一個設計。

我的錯誤是：我嘗試先創建問題領域中的類，然后將這些類縫合起來形成最終的系統--Alexander把這樣的過程稱為"一個壞主意"。我從來沒有問過自己：我是否擁有正確的類？僅僅因為這些類看起來如此正確、如此明顯。我擁有的，是在我開始分析時立刻進入了我的腦海的類，是我們的老師告訴我們應該在系統的描述中尋找的"名詞"。但是我的錯誤就是我僅僅嘗試把它們簡單的放在一起。

當我回過頭，開始使用設計模式和Alexander的方式來指導自己創建我的類時，僅僅幾分鐘之后，一個優秀得多的解決方案在我的腦海中顯露出來。這是一個很好的設計，于是我們把它應用在產品之中。我很興奮--為我設計了一個好的解決方案，更為設計模式的威力。從此，我開始在自己的開發工作和教學中結合設計模式。

我開始發現，那些剛開始學習面向對象設計的程序員也可以學習設計模式。并且他們可以在這個學習過程中為自己的面向對象設計能力打好基礎。這對于我自己是真的，對于我所教的那些學生也是真的。
想象一下我的驚訝！我讀過的設計模式書籍和與我交談過的設計模式專家都曾經告訴我：在開始學習設計模式之前，你真的需要認真進行面向對象設計的基礎訓練。然而，我用我自己的眼睛看見，同時學習面向對象設計和設計模式的那些學生，他們掌握面向對象設計的進度比那些只學習面向對象設計的學生更快。甚至他們掌握設計模式的進度看上去幾乎和那些有經驗的面向對象實踐者一樣快。

我開始把設計模式用做我的教學基礎。我開始把我的課程叫做"面向模式設計：從分析到實現的設計模式"。

我希望我的學生能理解這些模式，并且我發現使用一個探索的過程是幫助他們理解的最好辦法。舉個例子，我發現如果要向學生們講解Bridge模式，我最好能向他們展示一個實際問題，然后讓他們嘗試為這個問題設計一個解決方案。我會給他們一些指導性的原則和策略--我發現大多數設計模式都指出了這些。經過這個探索過程，學生們最后找到了解決方案--被稱為Bridge模式--并牢牢記住了它。

無論如何，我還發現這些指導性的原則和策略可以用來"派生"出這些設計模式中的幾個。"派生出一個設計模式"，我說這句話的意思是：如果我看到一個問題并且知道可以用一個設計模式來解決這個問題，我就可以通過這些指導性的原則和策略來得到該模式所表達的解決方案。我向我的學生們明確指出，我們不會真的通過這種方法得到設計模式。我只是闡明一種可能的思考過程。模式的發現者通過這樣的過程得到了最初的解決方案，并最終把解決方案歸類成設計模式。

一段小小的離題

在我現在看來，這些指導原則及策略都非常清楚了。當然，它們在"四人幫"的設計模式書中都有描述。但是，由于我自己對面向對象范式的理解有限，我花了很多時間來理解這些原則和策略。直到我在自己的思想中結合了四人幫及Alexander的工作、Jim Coplien在通用性和可變性上的工作、Martin Fowler在方法論和分析模式上的工作之后，這些原則對我才算足夠清楚，我才能和他人談起這些原則。這幫助我決定開始為他人解釋一些東西的生活，這樣我不會過分輕易的假想自己的能力--當僅僅為自己工作時，我很容易產生這樣的假想。

我的能力可以幫助我更好的解釋這幾個很有威力的原則和策略。并且當我開始解釋更多四人幫的模式時，它們更加有用了。實際上，在我設計模式課程中，我用這些原則和策略來解釋12到14個模式。

我還發現，我開始在自己的設計中使用這些原則，不管是否使用設計模式。這并沒有讓我感到驚訝。如果使用這些原則和策略最終讓我的設計中出現了一個設計模式，這就是說它們給了我得出優秀設計的方法（因為設計模式都是已經得到承認的優秀設計）。如果使用了這些技術，難道我還會因為不知道某個模式--不管它是否出現--的名字而得到不好的設計嗎？

這些領悟幫助我更好的進行我的訓練過程（以及我現在的寫作過程）。我已經把我的教學進行了好幾個階段。我正在向學生們教授面向對象分析和設計的基礎。我在課程中教授設計模式、使用它們來闡述優秀的面向對象分析和設計的例子。另外，通過使用設計模式來教授面向對象概念，我讓我的學生們更好的理解了面向對象的原則。而且通過學習指導性原則和策略，我的學生們現在可以創建出質量與模式相媲美的設計。

我在這里講這個故事，因為本書所講的模式幾乎與我的課程所講的一樣。實際上，從第三章開始，這本書基本上就是我的兩天課程--面向模式的設計：從分析到實現的模式--中的第一天。

閱讀本書，你可以學到這些模式。但更重要的是，你可以學到：為什么它們可以起作用？它們怎樣在一起工作？以及它們所依賴的原則和策略。這對你積累自己的經驗將很有幫助。當我在本書中展現出一個問題時，如果你能聯想到一個你曾經歷過的類似的問題，這將對你很有幫助。本書并不講述新的知識或新的模式，而是給你一個看待面向對象軟件開發的新的視角。我希望在你的學習過程中，你自己的經驗與設計模式的原則結合之后能形成一個強有力的聯盟。

Alan Shalloway
2000年11月

補充：
我們不能一直的只顧著寫程序，需要學習設計模式，況且java是純面向對象的語言

個人認為如果一個程序員不懂設計模式的程序員和不懂數據結構的程序員一樣，都是一個不合格的程序員！！！