淺談學習設計模式

物件導向、元件技術、分散式元件技術、設計模式、敏捷開發……短短的十幾年前IT界猶如時尚界一樣不斷湧現各種新潮的東西——所有的這一切的一切都為了“複用”。軟體開發是一件非常複雜的事情，其複雜性的體現足夠用一本書來說明——《人月神話》。“焦油坑”現在通常用來比喻陷入麻煩的專案；“沒有銀彈”的詛咒了軟體行業整整10年，真的沒有出現任何一種軟體開發方法、任何一種工具能把軟體開發複雜度在十年體提升十倍；那個經典的論斷——人才是制約軟體開發的唯一因素，除此之外別無其他直批軟體開發最本質的的一面。面對軟體的複雜性，人們想了很多辦法。比如有人提出了，能不能用抽象的手法把系統的各個模組定義出來，於是就有了物件導向；還有人說，“物件”抽象的粒度太細，我們要像硬體工程師學習，於是就有了元件；還有人從軟體開發過程著手於是就有了軟體工程；所有的這一切都是試圖通過各種“複用”的方式降低軟體開發複雜度。

設計模式也不是一個例外，它也是一種複用手段。它的提出者—— Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides（統稱為GOF、Gang of Four ~_~!!），1995年這四位博士合作寫了一本200多頁的書闡述了一種新的“複用”方式，這個方法為“設計模式”，這個本書叫《設計模式——可複用物件導向軟體的基礎》

GOF認為在世界上中存在一種可以複用“模式”，比如寫劇本的都會有一定的格式、用詞、甚至雷同的地方（就像TVB的經典臺詞 ），比如搞建築的當設計門、窗、房屋結構的時候也會按照一定的“模式”。於是GOF就試圖去總結軟體開發也存在的“模式”，他們找到了23個然後記錄在他們的書裡。GOF欣喜若狂，他們認為發現了一種非常非常了不起的軟體開發方法，用這種方法可以有效降低軟體開發複雜度。（他們那個時候估計忘記了“沒有銀彈”的詛咒）在書中他們闡述了設計模式的意義
1. 語言的進步， 人類之所以能從猿進化成“人”是由於人類有豐富的語言甚至為之派生類一個新的學科——文學；語言的簡練、專業是一個種族、一門學科進步的最大表現。（有興趣的可以去看一下康德為什麼在哲學史上如此重要，TAOCP和高德納為什麼會在電腦科學發展史上那麼不可動搖）GOF認為設計模式提煉了一些專業名詞，比如：“這個資料庫連線用‘工廠模式’就可以解決相容其他資料庫的問題了”人們不必去解釋什麼是工廠模式，這些專業詞彙是成為了這個行業的通用語言。
2. 經驗的複用，因為設計模式是一種經過千錘百煉的通用解決方式（正如TVB裡安慰別人必須要有的“做人呢，最要緊就是開心。”）所以它可以被直接套用，而且它可以成為一種目標，把“壞的程式碼”修改成這種模式就變成“好的程式碼”了；菜鳥還可以用它“照葫蘆畫瓢”做出更加符合物件導向的設計。

好了關於設計模式的介紹就到這裡，下面進入正題說一下如何正確學習和使用設計模式。關於設計模式我的所有知識都來自那本《設計模式——可複用物件導向軟體的基礎》，我也讀過市面上其他的書就我個人感覺這些書要麼引入“玄而又玄”的東西不寫個1000頁不罷休；要麼就是像23個設計模式一樣編寫一堆新的設計模式條目。要學懂設計模式我覺的應該先理解設計模式的真實意圖——可複用物件導向軟體的基礎，這是那本經典名著的副標題，正如我們開頭說的，GOF是也是為了軟體的複用而才有的設計模式。

既然為了複用我們不妨放開思路——只要能夠達到軟體複用的目的我們可以不必有那麼多顧慮、可以不折手段，不管是設計模式、物件導向還是TDD，敏捷開發，只要能讓軟體複用，能降低複雜度我們就可以利用。如此一來我們便有了“主動權”，我們不必循規蹈矩的去看設計模式，也不必循規蹈矩的去畫UML、寫用例、寫單元測試，我們需要弄清楚所有的這一切它們達到“複用的方法”是什麼？這個方法便是以後我們要對付軟體複雜度的有力武器。設計模式，它之所以能實現複用是因為它總結了我們在物件導向設計中“更加物件導向”的設計方案，這些方案被用一種方式記錄下來。既然如此我覺得學習設計模式的思路也應該是——從物件導向出發，不考慮我們要用什麼模式而考慮我們要如何物件導向，以此為基礎最終我們的設計會和設計模式保持一致（即便不保持一致，最後我們的設計方案也是要優於設計模式更加貼近現實）。只要這樣利用設計模式我們才不會為了設計模式而設計模式（有句話說：當你手裡拿著錘子的時候，全世界都是釘子）才不會誤用設計模式。

這就猶如我們解數學題，正常的人是沒有辦法看到題目就知道要應用某某定理、某某推論直接得到答案的。必然是以“解題”為目標，充分利用各種條件、定理、推論，最終成功解題。同樣正常人看到某個設計為也是沒有辦法直接得到答案的，必然是以“物件導向”為目標，充分利用“繼承”“封裝”特性，最終成功完成簡潔的設計。