系列鏈接地址： 深入理解設計模式 系列目錄 一、產品汪的神助攻，代碼狗的安慰劑 定義：設計模式，指的是一個場景(context)下的一種解決方法（Solution），只要大家都認可某種模式，那麼就只需要很短的一個名字，就可以代替很多很多的語言和文字交流，如果你覺得設計模式降低生產效率，那隻能說你在這 ...
系列鏈接地址： 深入理解設計模式---系列目錄
一、產品汪的神助攻，代碼狗的安慰劑
定義：設計模式，指的是一個場景(context)下的一種解決方法（Solution），只要大家都認可某種模式，那麼就只需要很短的一個名字，就可以代替很多很多的語言和文字交流，如果你覺得設計模式降低生產效率，那隻能說你在這一行還要繼續修煉。
宗旨：保證系統的低耦合高內聚，指導它們的原則無非就是封裝變化，責任單一，面向介面編程等設計原則
目的：就是為了讓代碼變得更容易理解和維護
精髓：將複雜的邏輯抽離出來，讓開發人員真正專註於業務代碼，系統，那麼設計模式會加大理解難度。但當你看懂之後，你會發現這麼做真是太巧妙了！
設計模式無非就是把代碼抽象出一個更高的層次，再來實現原先想要實現的功能，設計模式是有代價的，以複雜度換取靈活性，，說到底是為了給自己留條後路，在代碼走向可能發生變化的點上留下靈活性的種子。
二、設計模式是黏合劑
我最初在學習設計模式的過程中由一種困惑，“這樣繼承封裝多態亂七八糟的繞來繞去的幹嘛？”後來慢慢的隨著經驗的積累才知道是迫不得已，這種迫不得已，有很多種原因。個人覺得最容易理解的就是“適配器模式”，因為出現了介面的衝突，所以我們不得不進行適配。但一個很自然的問題就是：為什麼不直接改介面讓他們自然融洽呢？這不是一種更自然更直觀的解決方案嗎？答案很有可能就是因為架構，大的架構已經確立，局部必須服從整體。
那麼，如果一個完全理想化的架構，是不是根本就不應該出現這種問題介面衝突的問題，因而根本就不需要這種設計模式？
不是的，設計模式是黏合劑，它的作用是彌補架構的局部缺陷，更好的支撐架構。更極端的一種說法可以送給痴迷於設計模式的同學：設計模式是藥，沒病就不要吃藥！
設計模式是為了封裝變化，讓各個模塊可以獨立變化。精準地使用設計模式的前提是你能夠精準的預測需求變更的走向。我們都知道大部分人是做不到的，所以大部分人就算精通設計模式也多少會做錯點什麼東西。所以這其實不怪設計模式，怪產品狗</del>。所以說如何避免過度設計，這就要求你深入的理解你的程式所在的領域的知識，瞭解用戶使用你的軟體是為瞭解決什麼問題，這樣你預測用戶的需求才會比以前更加準確，從而避免了你使用設計模式來封裝一些根本不會發生的變化，也避免了你忽視了未來會發生的變化從而發現你使用的模式根本不能適應需求的新走向。
三、模式無處不在
要為實現需求而編碼，而不是為使用設計模式而編碼。象張無忌學太極一樣，學會了，然後忘了，不要刻意使用設計模式，模式無處不在。
很多同學在學習設計模式的時候看到的只是結果，並不瞭解過程和動機，也就是其他人在什麼樣的情況下做出這樣的設計，而這個恰恰是各種教程、資料上學習不到的。
在幾年前我自己制定了類代碼行數不超過600，函數行數不超過60，嵌套不超過3層的編碼規則。這個規則非常明確，比“高內聚，低耦合”之類的可執行性高多了，我自己實踐過程中，一旦違反這條規則的時候，就不斷的重構至這個目標。
經過3，4年的實踐，基本上做到了任何時候、場合都符合自己所制定的規則。現在閱讀我寫的代碼的時候，往往能發現其中有些地方符合一些設計模式的地方。回過頭思考設計模式的時候，悟出了開篇關於設計模式學習、應用的那個弊端。
四、脫離業務需求談設計模式都是耍流氓
離開具體業務需求談設計模式都是耍流氓,OOP的世界里出現設計模式是為了讓程式更有彈性,易於擴展。而且經過這麼多年的發展,前輩們從具體的業務需求抽象出很多種的設計模式，設計模式，是為了需求變動而產生，拋開需求談模式，顯得很蒼白。
沒有完美的設計模式，它只適應於特別的場合，要理解和掌握設計模式，要從發現需求變動， 準確找到變化點，如何封裝它的角度去研究，去學習，而不要拘泥於具體的形式。換句說話：在23種設計模式的需求中，要準確找出哪些地方是強耦合，並且由於實際需要，要對這些耦合進行解耦。這樣才是真正的理解了設計模式。
