值得收藏，方便以後查找，參考鏈接：http://www.cnblogs.com/wangfupeng1988/p/3687346.html
1. 前言
設計模式——最熟悉的陌生人。
很多人應該都有這種感受，早就知道設計模式，也能隨口說出幾種，但是不知道每種是怎麼回事。或者說只知道工廠模式等幾個常用，簡單的。估計那也是靠記憶，而不是真正的理解。
我也有這種親身體會，在好幾年之前就知道設計模式。之前也一直抽時間學，但總是學了就忘。而且學習過程很枯燥，完全是背誦式的記憶那些類圖，不是真正的理解，更別提應用了。
2. 關於“設計”
設計，就是爲了更好的應對變化。沒畢業時候不知道軟件系統怎麼會有變化，但是工作之後慢慢就會發現，變化，那叫一個天馬行空。。。
一提到“設計”，大部分人可能會直接想到設計模式，而且是23種設計模式。其實這是錯誤的。其實學會設計、應用設計，應該分爲四個層次：
2.1 面向對象
首先要了解面向對象，什麼是面向對象？什麼是封裝、繼承和多態，以及三個特點的表現形式。基礎很重要。
要想充分了解面向對象，三個特點，最好還是按部就班的參考一本權威書籍，看看書上說的你是不是真的理解。看看繼承和多態的表現形式你是否都知道。
如果沒按部就班看過書，就不要以爲自己都會了。借用某相聲演員一句話：“你以爲你以爲的就是你以爲的？”。。。
2.2 抽象與具體
如何更好的解決“變化”問題？答案是“提取抽象、隔離具體”。
什麼是“抽象”？ 抽象就是不變的東西，一個數據表的操作，總會有增刪改查，把他們作爲接口，這是不變的。
什麼是“具體”？ 具體是實際執行的，一個數據表的增刪改查，用sqlserver、access還是oracle？可能會有變化。
我們應該依賴於抽象編程，而不是依賴於具體編程。應該把程序中的共性抽象出來，並且把具體實現的部分隔離開來，讓他們都依賴於抽象，並且互不影響。這其實就是設計。
只有理解了“抽象”、“具體”、“隔離”這幾個詞兒，你才能真正理解設計模式。否則就別指望。
2.3 SOLID五大原則
系統設計的5大原則，簡寫分別是S、O、L、I、D。
- S - 類職責單一原則： 即職責劃分要清晰，不同職責的不要攪和在一起。每個類應該只有一個讓他發生改變的原因。
- O - 開放封閉原則： 對擴展開發，對修改封閉。即如果系統要變化，就去擴展、新增新類，不要修改現有的類。
- L - LISKOV原則： 子類應該能充分覆蓋父類，並且讓使用者分不出差別。
- I - 接口分離原則：每個接口只管一個功能，不要出現“胖接口”。增加功能時，要加接口，而不是改接口
- D - 依賴倒置原則：具體應該依賴於抽象，而不是抽象一來於具體，即低層要依賴於高層。
對於以上5大原則，此處不詳細解釋，有興趣的可以查閱《你必須知道的.net》第二版，裏面講的非常詳細。
如果詳細分析這5大原則，其實他們都是圍繞着“提取抽象、隔離具體”來的。
- S - 類職責單一原則： 隔離
- O - 開放封閉原則： 依賴於抽象，隔離具體
- L - LISKOV原則：抽象
- I - 接口獨立原則：隔離
- D - 依賴倒置原則：依賴於抽象
2.4 設計模式
最後纔是設計模式，設計模式其實是一些工具而已。
是“術”，不是“道”。如果你不明白以上那些“道”，而直接去學“術”，肯定是學一次忘一次。
在看每個設計模式的時候，你都要去向着這個方向去思考：它是不是提取了抽象、分離了具體、依賴於抽象、封裝了具體？ 這樣一來，你就會明白了。
3 例子：工廠模式
工廠模式在設計模式中分三種：簡單工廠、工廠方法和抽象工廠，其實這三種對應了不同的抽象程度。 下面簡單分析前兩種。
3.1 簡單工廠：
看上圖，很明顯是“提取抽象，分離具體”。將數據操作的接口提取出來，交給不同的實現類來實現。
工廠類返回的是IDBHelper接口，即客戶端會調用IDBHelper接口，而不需要關心具體實現，這就是“依賴於抽象，而不是依賴於具體”。
還符合“開放封閉原則”，例如現在又要用DB2數據庫，那麼再加一個實現類就行，無需改其他地方。客戶端也不會察覺後臺的變化。這就是：對擴展開放，對修改封閉。
簡單工廠之所以叫“簡單”，是因爲它的工廠類還依賴於數據操作實現類，這違反了“依賴倒置原則”，那麼該怎麼辦呢？
3.2 工廠方法：
上文說了，簡單工廠類依賴與數據操作實現類，當前有3個實現類，那麼工廠類肯定需要判斷，免不了有if else或者swicth case語句，
switch (type) { case "sqlserver": return new SQLDBHelper(); case "oracle": return new OracleDBHelper(); case "access": return new AccessDBHelper(); default: throw new Exception("type參數錯誤"); }
而這些語句，就是設計模式重點要改進的地方。
如何讓工廠類不依賴於數據操作實現類？ 答案還是“提取抽象，分離具體實現”。
將工廠類的具體職責抽象出來，然後分離一些實現類，分別實現各自的功能。
4. 總結
學設計模式不容易，需要熟悉語言、面向對象、理解設計原則。。。。即便是都看會了，理解了，到了應用又是個麻煩事兒。
有一位大牛說過：《設計模式》這本書，我們要像字典一樣經常拿出來翻翻看看，而不是通篇看完就算了。
可見，它需要我們長期的“學習 - 應用 - 總結 - 學習”，才能更好的理解。
另外，我感覺在系統設計中，也沒有必要非得去套用設計模式，只要符合設計原則，符合開發、運行效率，怎樣設計都行，不要爲了用而用，濫用不如不用。
話又說回來，還是對設計大原則，對“道”的理解。