從物件導向到模式再到真正的物件導向 (轉)

從物件導向到模式再到真正的物件導向 (轉)[@more@]

從面向到再到真正的物件導向
 Alan Shalloway 著 透明  譯

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

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

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

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

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

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

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

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

 我實在覺得很受挫，於是我停了下來，開始繞牆行走以清醒頭腦，並告訴自己：至少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月