## 連載：面向對象葵花寶典：思想、技巧與實踐（38） - 設計模式之道 很多人能夠熟練背誦出所有的設計模式，能夠快速畫出各種設計模式的UML類圖，也能夠熟練的寫出《設計模式》一書中各個模式的樣例代碼。但一到實際的項目設計和開發的時候，往往都會陷入迷茫：要么無從下手，不知道哪個地方要用設計模式；要么生搬硬套，胡亂使用設計模式，將方案和代碼搞得一團亂麻。 =========================================================================== ### 【知易行難?——?設計模式應用的問題】 形而下者謂之器，形而上者謂之道。 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?---《易經·系辭》 ? 正如很多流行的技術（面向對象、UML等）一樣，幾乎大部分人都會宣稱自己“掌握、熟練掌握”，甚至“精通”，然而，真正掌握的或者精通的，實在是少之又少。 ? 一種典型的現象是：很多人能夠熟練背誦出所有的設計模式，能夠快速畫出各種設計模式的UML類圖，也能夠熟練的寫出《設計模式》一書中各個模式的樣例代碼。但一到實際的項目設計和開發的時候，往往都會陷入迷茫：要么無從下手，不知道哪個地方要用設計模式；要么生搬硬套，胡亂使用設計模式，將方案和代碼搞得一團亂麻。 ? 這是什么原因呢，難道是設計模式不好用，或者設計模式根本就是一個噱頭？ 答案不在于設計模式本身是否有用，而是在于我們沒有掌握正確的學習和應用設計模式的方法。 ? 學習《設計模式》一書中的23個設計模式，只是掌握了《設計模式》的“器”，但并沒有掌握設計模式的“道”。就像一個工匠，鋸、鉆、錘、刨樣樣精通，但如果不知道什么地方該用鋸，什么地方該用鉆，肯定是一個不合格的工匠。為了能夠更好的學習和應用設計模式，我們也需要掌握設計模式的“道”。 ? 設計模式的“道”就是用來指導我們什么時候用設計模式，為什么要用設計模式，23個設計模式只是告訴了我們how，而設計模式之道卻可以告訴我們why和where！ ? ### 【撥云見日?——?尋找設計模式之道】 熟悉《設計模式》一書內容的同學可能會想到：《設計模式》一書中，不是每個模式都有“適用性”的說明么？這個其實就是回答了where和why的問題啊！ ? 例如：Facade模式的“適用性”說明如下（摘自《設計模式》中文版一書）： ? 上面這一段文字，看起來回答了where和why的問題，但實際上我個人感覺作用并不大。 ? 首先，這段描述太長了：以上這段文字是否花了你幾分鐘的時間去閱讀和理解？ ? 其次，這段描述比較抽象：什么事復雜，什么叫做簡單，什么叫做很大依賴性。。。。。。可能每個人理解都不一樣。 ? 再者，23個模式，所有的“適應性”條款加起來估計有幾十條條，你能夠背住么？即使你能夠全部背住，你能夠全部理解么？即使你能夠全部理解，當面對一個具體問題的時候，你知道幾十條里面哪一條適應你的情況么？ ? 所以，《設計模式》一書關于“適用性”的描述，實際上還是太復雜，太多了，不具備很強的實踐知道意義和可操作性。 ? 我們需要的是一個更簡單的指導思想，大道至簡，最好是一兩句話就能夠描述！ 幸運的是，答案竟然就在《設計模式》一書中，但這個答案并不是那么明顯！ ? 《設計模式》一書的內容側重點是23個模式的詳細闡述，大部分人可能都是直奔主題，逐一去研究每個模式，而對于開頭部分第1章和第2章的內容并沒有詳細研讀和思考，或者對于這兩章只是簡單的瀏覽，并未認真領會和思考，由此錯過了最重要的內容。再加上GoF在這2章的內容中，既要引入一個全新的概念，又要提綱挈領的介紹各個模式，還要引入實例進行分析，以至于大量的內容將真正核心的內容反而給淹沒或者沖淡了。 ? 設計模式之道就隱藏在“2.6.2?封裝實現依賴關系”的最后一段，很簡單的一句話： **對變化的概念進行封裝（encapsulate?the?concept?that?varies）** ? 你看到這句話可能有點失望，前面分析了那么久，賣了那么多的關子，結果就這么簡簡單單一句話，這不是在忽悠么？ 你可千萬別小看了這句話，“大道至簡”，設計模式之道也不例外，但“簡”并不意味著沒用，相反，正因為其“簡”，每個人的理解才一致，也更好掌握，實踐中才更好應用。正所謂：“真傳一句話，假傳萬卷書”。 ? GoF在《設計模式》一書中最早提出這個原則，后來不斷的有其他專家進行闡述，其中《設計模式精解》（《Design?pattern?explained》）一書的闡述我認為是最精辟的：**Find?what?varies?and?encapsulate?it，翻譯一下即“找到變化，封裝變化”**。雖然含義和GoF描述的基本一致，但其更加容易理解。 ? 正所謂：踏破鐵鞋無覓處，得來全不費工夫！ ### 【庖丁解牛?——?解析設計模式之道】 現在，讓我們來深入理解“找到變化，然后封裝變化”的設計模式之道。 首先，“找到變化”解決了“在哪里”使用設計模式的問題，即回答了“where”的問題。 ? “找到變化”看起來是比較抽象的一句話，但在實踐中非常好應用和操作，而且不同領域、不同行業的系統都可以完美的應用這句話。雖然不同領域、不同行業變化的因素、方式、時機等都不一樣，但每個領域或者行業的需求分析人員、設計人員，對自己所處行業和領域的可能變化肯定是有比較深刻的理解的，什么會變化、會如何變化、什么時候會變化。。。。。。等等，肯定都能夠自己判斷，這種判斷并不需要什么高深的技巧和知識水平，只需要一定的經驗積累。 ? 如果我們剛接觸一個行業或者領域，經驗積累并不夠，那怎么辦呢？是否就無法“找到變化”了？ 其實也不然，有一個萬能的辦法，只是要花費更多的精力了。 ? 我的這個萬能辦法就是“唯一不變的是變化本身”，也就是說，如果你不知道什么會變化，那么就抱著懷疑一切的想法，一切都可能是變化的。 ? 但光有這條指導原則還不行，如果我們真的抱著“一切都是可能變化的”想法，然后封裝一切變化，那么就會陷入變化的漩渦無法自拔，因為變化是會遞歸的，A可能變成B，B也可能繼續變化，于是這樣無窮無盡，系統是不可能做出來的。 ? 所以我們需要一個終止條件，避免陷入無窮無盡的變化遞歸漩渦。這個終止條件就是“有限時間內可能發生的變化”。這里的“有限時間”隨行業和領域的不同而變化。例如（以下時間僅供參考）： 互聯網行業可以說：半年內可能發生的變化。。。。。。 電信行業可以說：1年內可能發生的變化。。。。。。 金融行業可以說：2年內可能發生的變化。。。。。。 政府行業可以說：3年內可能發生的變化。。。。。。 ? 有了這個指導原則后，你可以這樣去問有經驗的前輩、大蝦、大牛等：?XXX在1年內會發生變化么？會怎樣變化？ ? 就這樣，即使你是菜鳥，通過這么一招“借花獻佛”，也能夠輕松發現“變化”的地方。 ? 其次，“封裝變化”解決了“為什么”使用設計模式的問題，即回答了“why”的問題。 為什么我們要用設計模式，是因為我們要封裝變化！但我們為什么要封裝變化呢？ 答案很明顯：變化不好！ ? 當然這個“不好”不是從業務的角度來說的，而是從系統的角度來說的。從業務的角度來說，“變化”是好的，變化意味著新的機會；但從系統的角度來說，變化并不好，因為變化必然要求系統改動，改動就意味著風險！ ? 雖然變化給系統帶來風險，但我們不能因此而“拒絕變化”，因為拒絕變化就意味著失去了機會，簡單來說，賺不到錢的系統，設計再優美，功能再強大，系統再穩定，也不過是一堆無用的擺設： 客戶給你提了新需求，你不做，能拿到合同么。。。。。。 行業正在興起新的流行功能，你不做，你的系統有人用么。。。。。。 一項創新帶來了新的機遇，你不做，能搶占市場么。。。。。。 ? 所以我們要“擁抱變化”，但我們又不能讓變化帶來太大的風險，所以就提出了“封裝變化”。“封裝變化”意味著將變化的影響范圍控制最小，將風險降到最低。 ? 我們來看看，變化會帶來哪些問題和風險： 1）開發人員需要編碼以適應變化，設計不好的方案將導致大量的編碼工作量、自測工作量； 2）測試人員不單要測試因變化而新增的那部分，還要測試受影響的部分，設計不好的方案，牽一發而動全身，導致測試工作量大大增加； 3）如果為了適應某個變化而對系統做了比較大的改動，則系統的質量風險將上升，很可能導致上線失敗，或者上線后出現各種問題； ? 因此，我們要盡量減少變化帶來的工作量和風險，而減少的最有效方法就是將變化的影響范圍縮小，即：將變化封裝起來，使其只在有限的范圍內有影響。 ? ### 【舉一反三?——?活學活用設計模式之道】 就像一個武林高手有了深厚的內功，天下萬物皆可成為手中的利器，而不必拘泥于具體的武器和招數一樣，掌握了設計模式之道后，我們其實也完全可以不拘泥于只是用《設計模式》一書中的23個設計模式，可以根據需要選擇最合適的方案。 ? 例如： 不同的業務有不同的規則排列組合，規則引擎可以封裝各種變化的規則。。。。。。 類之間的依賴是變化的，Spring使用XML配置文件來封裝這種變化。。。。。。 每個銀行的卡都不一樣，銀聯封裝了這種變化，使得不同銀行可以互通。。。。。。 ? 總之，你可以使用類和設計模式來封裝變化，你也可以使用配置文件和模塊來封裝變化，你也可以使用一個系統來封裝變化。。。。。。