robbin談如何學習設計模式

源自：http://www.kuqin.com/beginner/20054.html

備注：設計模式的根本也是為了代碼重用，那隻要你做到了很好的代碼重用，你是否是否了GOF 設計模式23種之一根本不重要，首先是目标明确，再尋找有效的手段，而不是先我知道一種很好的方法，我要把他運用到那裡去。

    随便談談我對設計模式的看法吧。我極度反感言必稱設計模式，什麼要學好OO，必先學好Gof這類的屁話。坦

率說我也從來不刻意的去學習設計模式，我看到身邊的朋友花那麼多錢去買一大學厚厚的閻博士的設計模式的書，心裡總是歎息一下，設計模式不是學出來的，是用

出來的。設計模式應該怎麼學習？應該我花兩個小時給你講一下，告訴你每個模式是怎麼回事，應該在什麼場合适用就OK了，這樣就學完了。

然後你在自己的工作實踐中，碰到了這類問題，想起來自己曾經聽xx說過可以使用xx模式，于是乎，你再把閻博士的書打開看看(或者把

banq的文章翻出來看看)，進行   copy &

paste。這樣就夠了，充分夠了。你真的完全沒有必要把模式看的多麼神聖，多麼神秘，多麼高深，它就是一個讓你去copy &  

paste的代碼片斷，如此而已。是以Gof的書那麼薄，因為作者知道設計模式本來就不是一個可以學出來的東西，是以Sun的J2EE模式就算加上了冗長

的代碼和羅嗦的描述，也是薄薄一本。把一本模式的書寫的如此之厚，我認為已經失去了學習它的價值了。

而且“設計模式”這個詞彙廣義的來說指的是适用于特定場合的經過驗證是良好的解決方案。其實隻要你有足夠的工作經驗，就算你沒有學過設計模式，

你寫出來的代碼也會不知不覺符合某種模式的要求的。因為你經過很多實踐經驗，你已經積累了很多，你知道在什麼場合代碼應該怎麼寫，那麼“在什麼場合代碼應

該怎麼寫”這本身就是設計模式。

是以我認為沒有必要刻意去學習設計模式，也沒有必要把設計模式當做多麼神聖的東西。隻要你的OO程式設計經驗達到了一定的水準，設計模式本來就是無師自通的。如果你的程式設計經驗很少，你就是把Gof背得滾瓜爛熟，到時候你一樣用不出來。

設計模式就像圍棋中的定式，如果你是高手，你下的棋自然而然的符合一些定式的走法，如果你是初哥，你就是背了幾千個定式，隻要對手不按照定式來走，你就一點都用不上。

再說Gof的23種模式隻不過是設計模式的滄海一粟，Sun的J2EE有15種設計模式，你還要不要學，要不要背？  

不說别的，Hibernate現在也出了20種設計模式了，那是不是說你不把Hibernate的20種設計模式背的滾瓜爛熟，你就不可能把

Hibernate學好用好呢？

總結一下我的觀點：

設計模式就是定式，碰到這種場合你才用得上，是以學習設計模式，你隻需要花2個小時過一遍，腦子裡面有個印象就趕快收手，到用的時候再去copy &   paste。這樣就夠了。如果你告訴你花了幾個月去鑽研設計模式，我隻能告訴你，你在浪費青春。

總之，水準沒到，學也白學，水準到了，無師自通。是以不要學設計模式，看一遍就用，用多了，你自己也可以總結設計模式了。

評論

dlee 2003-12-24 16:56

我比較贊同 robbin   的看法，雖然我學習設計模式花費了不少時間（一兩個月吧）。設計模式應該象手邊的工具箱一樣，我需要一把尺子就拿一把尺子來用，需要一隻圓規就拿一隻圓規 來用，沒有必要神秘化。在有些場合，如果不可能發生大的變化，就不要用設計模式，而用更簡單的代碼來實作。擁抱變化并不意味着過度設計。                其實我們在開發中一些常用的注意事項和解決問題的通用套路就是設計模式。                《設計模式》這本書确實不太适合初學者，因為書的作者主要注重的是準确性而不是可讀性。這也是這本薄薄的小書我看了一個月之久的原因。也是為什麼會有那麼多解釋這本書的書出現的原因。                但是我的趣味是直接閱讀大師的原著，那些讓我感到痛苦的書往往收獲是最大的。我第一遍讀這本書的時候相當于是郭靖背九陰真經，現在一年半時間過去了，總算有了一些比較深入的了解。                這個文章讨論設計模式似乎是不太合适，呵呵。

ozzzzzz 2003-12-24 16:58

ribbin                嘿嘿。我覺得看看閻博士的書還是對初學者還是很有幫助的，至少他們可以從那本書中明白正方形不是長方形的子類。但是要是依賴那本書進入設計模式的大門是不可能的，就是GoF的書我也不認為能讓誰入門。                在我看來設計模式也好，RUP也好，XP/AGILE也好都是工具，都有限制。知道什麼時候用設計模式不重要，重要的是知道什麼時候不要用設計模式。就這一點閻博士承認他的書沒有對這個問題作深入的探讨。                你用定式來說明設計模式很好，而學習定式的最佳途徑就是實際使用定式。是以你說“設計模式不是學出來的，是用出來的”。                GoF自己說他們并沒有發明設計模式，而隻是發現了設計模式。這就告訴我們可以通過積累發現新的模式。但是作為初學者還到不了無師自通的地步。要想提高水準，還必須學習一些前人的經驗，而看看那些别人寫的書還是對他們很有幫助的。                不要自己發明輪子，是不是？學習一些套路還是對于提高水準有幫助。                學習也不能盲目，沒有什麼東西是打遍天下無敵手的。

孤魂一笑 2003-12-24 17:11

ozzzzzz:                你把robbin 的名字寫錯了，允許你say sorry.開玩笑了。 實用點吧，設計模式的根本也是為了代碼重用，那隻要你做到了很好的代碼重用，你是否是否了GOF 設計模式23   種之一根本不重要，首先是目标明确，再尋找有效的手段，而不是先我知道一種很好的方法，我要把他運用到那裡去。                    至于他們兩個人，我們也沒有必要去評價。畢竟我們很多事情不清楚。

ozzzzzz 2003-12-24 17:29

robbin                sorry。把你的名字和我另外一個朋友的名字搞混了。該死該死。                孤魂一笑                在我看來GoF當然是為了重用，但是不僅僅是重用，特别是代碼的重用。可以說沒有GoF就沒有architecture和framework，設計模式可 以說是現在設計的核心基礎，它給了我們一個認識問題解決問題的途徑。但是不能就此認為設計模式是什麼玄奧無比難于掌握的東西。                設計的本質在于權衡，而GoF隻給我們提供了一個解決問題的方法，具體使用這種方法會有什麼後果還要我們自己去掌握。                我認為設計模式的根本其實在設計模式之外。

dlee 2003-12-24 17:43

我覺得了解了設計模式，再發現新的模式相對來說是比較容易的事情。但是如果完全不了解設計模式，自己也不容易發現新的模式，提高代碼的重用性也是空談。也許你自以為重用性已經最高了，但是别人用設計模式幫你重構一下後你發現居然還有那麼多重用性可以提高。                如果你象我的一個朋友一樣寫過幾十萬行代碼，獨立設計過多個開發架構。那麼設計模式對你來說确實不是非常重要。但是普通程式員并沒有那麼多機會開發大項目，是以深入學習設計模式還是很有必要的。                這個問題沒必要争論，不是要不要設計模式的問題，而是如何用好的問題。

zingers 2003-12-24 18:32

閻宏确實有把簡單問題複雜化的tend，既使是入門，也是以簡潔為勝，他這樣子狂舉傳說故事                與我欣賞的自明性原則不相容。 BANG如果用了他的圖，那也是不太好，不過BANG後來删掉了。

孤魂一笑 2003-12-24 18:34

設計模式肯定是要用的。                不過我是先按照自己的開始構想去實作代碼，這一步驟以達到目的為主，當然寫代碼的時候就會去考慮使用那些模式，在做重構的時候可能側重符合設計模式就更多點。我是很怕有些人為了設計模式而設計模式反而先給自己下個套。                很多是為了設計模式而設計模式那其實有點那個什麼。 再說一下閻博士的那本書，其實他在講述設計模式之前的那些OO原則的講述很不錯。

robbin 2003-12-24 18:50

引用 設計模式的根本也是為了代碼重用，那隻要你做到了很好的代碼重用，你是否是否了GOF 設計模式23   種之一根本不重要，首先是目标明确，再尋找有效的手段，而不是先我知道一種很好的方法，我要把他運用到那裡去。 我覺得這句話真的說到我想表達的意思上了。隻要你的代碼結構良好，至于到底有沒有所謂的設計模式，根本就是不重要 的了。打個不恰當的比喻，一個好的殺手，他的目标就是一劍封喉，幹脆利索的殺了目标，你管他殺人用的那一招究竟是華山派的什麼劍法，還是嵩山派的什麼劍 法。達到目标就行了。而且你的劍法練到一定的程度，你可以自創劍法，這個世界絕沒有你練熟了世界上的劍法，你就是絕頂高手的道理。至于你已經達到了高手的 境界以後，一招一式無不合劍道之極緻。，也就根本無所謂用什麼招式了。 感覺自己在胡說八道，引人入歧途，不過這是灌水版，還好還好。

ozzzzzz 2003-12-24 19:32

嘿嘿這次寫對了。                就是嗎？這個地方其實是談問題的最好地方，反正錯就錯了。誰也不認識誰。                不過我不怎麼同意你們關于GoF根本是為了重用代碼的說法，這樣說太看重代碼重用的了。設計模式還是一種解決方案的總結而不是具有實施的總結，它的所處的層次應該是在代碼層上，在framework層下。                “你是否是否了GOF 設計模式23   種之一根本不重要，首先是目标明确”這句話絕對正确，但是問題在于目标明确是非常困難的事情。為什麼說設計的本質是權衡，就在于你很難隻确定一個目标，更 難确定一個固定的目标。你要考慮的往往是在多種限制下的多種可能解決方案。我不認為有哪種解決方案是唯一正确的，這就是設計政策和風格的問題。作為初學者 肯定會經過一個癡迷于設計模式并且看到所有的東西都是釘子的階段，這不可怕。要是他們不經過這個階段，也不會到達無招的階段。                而在初學者成熟前，我認為讓他們先掌握幾種解決方案，然後去努力的在現實中尋找使用這些方案的合适場景是不錯的選擇。                是以不管他們兩個中的哪一個都是為初學者作了很多有意貢獻的人，是值得初學者學習的。                而我想初學者不能因為他們之間有沖突，就信奉一個排斥一個。

Anonymous 2003-12-25 12:49

設計模式我認為還是用出來的，就像Robbin說的那樣，不需要去刻意的學習設計模式的多少種模式，隻需要大體的 了解一下每一種設計模式他之是以這樣設計的好處，及大體的架構就ok了，那你每次進行設計或開發的過程中，或者在你遇到困惑的時候，就會不自覺地想到某種 模式可以給自己帶來友善和解決困惑，或者讓别人能更好的看懂之類的好處。。。而且在開發和使用模式的過程中會慢慢的提高自己的這方面的水準。              至于什麼bang，閻博士，不關心。演博士沒看過，bang的也是聽别人說jdon采來的，對收費比較讨厭，難道就缺那點錢？就算缺，也不至于這樣。

potian 2003-12-25 21:54

雖然我上次和Dlee在那個貼子裡面聊的時候說起過設計模式是基本知識，但從另一方面講，設計模式的重要性其實怎麼說都是不為過的。              首先，早期設計模式提出的時候是為了消除軟體出版界和研究界的一些偏差：以前一些文章和研究都隻是注重新技術，所謂的創新性。但其實在軟體行業，新的技術 層出不群，但很多基本的問題、很多現有技術足夠可以解決的項目卻沒有很好的完成，設計模式的提出者包括Kent   Beck,GOF和JimCoplien認為這是因為好的經驗沒有被足夠的傳播。是以在當時設計模式有點反叛主潮流的意思，但是這種反卻反出了大名堂。 《設計模式》被推崇為軟體行業有是以來最重要的著作之一,我想最重要的原因就是認識到舊技術的良好運用在絕大多數時候比新技術更重要。設計模式的提出不但 聲明了這種經驗的重要性，而且把它推上了大雅之堂。查一查IEEE論文，現在大學裡面研究設計模式的人大有其在。              第二個重要貢獻當然是軟體設計行話的标準化。之前的很多行話或過于細節、或過于粗略，完全達不到精确表達和有效應用的程度。但設計模式把這些場景和解決方 案固定化、細緻化，這是非常重要的。我喜歡把設計模式看作李商隐的詩歌，雖然不能突破李白、杜甫的創新，但是卻是整個有唐以來詩歌技巧的總結，是凝練了前 人經驗之上的升華。另一方面，這些概念的标準化把解決問題的起點從對象和方法提高到參與者結構關系和互相作用，毫無疑問可以把所有開發、設計、分析的水準 提高到另外一個層次，我想每個人在初學設計模式的時候都會有這個體會。（立體幾何的課後習題都有點小定理的意思，我記得以前學立體幾何問題的時候，總是把 課本後面的習題前提和結論都記牢，每次解題的時候我很少從正文的基本公式和定理開始推導、計算，而是針對問題的總前提，套用組合幾個習題的答案。這樣不但 快的多，而且有時候不這樣做比較難的競賽體根本就解不出來）。              另外我認為這些基本模式務必精通，其中意圖是最最重要的，解決方案則應該掌握好權衡，熟悉應用每一個模式的結果。在此基礎上，設計模式就可以大大提高軟體 人員之間交流的資訊量，很多複雜的問題可以通過簡單的詞彙進行讨論，因為大家都知道這一個簡單的單詞意味着什麼、其中的細節是如何的、這樣解決以後問題又 會變成什麼樣子（好像有點心有靈犀一點通的意思）。我感覺，資訊交流的頻度和容量也是長久以來美國人軟體超過中國人（或其他國家）的終極因素。              現在設計模式的作用則進一步展現在對程式設計方法和程式設計範式引導的作用。由于設計模式基本上展現了利用OO問題解決的最佳方案，是以它必然最充分地暴露出OO 的缺陷。我仔細閱讀過Visitor模式的論文大約有100多篇，很多人用反射、Meta、Closure、函數型程式設計等等試圖解決Visitor模式的 一些缺陷，都非常有見地。每一種新的程式設計範式，如AOP或舊的程式設計範式如functional,Smalltalk來示範自己的威力時都不約而同選擇了設 計模式絕不是偶然的。設計模式的典型性和示範作用無疑為新的語言和程式設計思想的發展奠定了良好的基礎。