個人總結：
設計模式——最熟悉的陌生人。
很多人應該都有這種感受，早就知道設計模式，也能隨口說出幾種，但是不知道每種是怎麼回事。或者說只知道工廠模式等幾個常用，簡單的。估計那也是靠記憶，而不是真正的理解。
我也有這種親身體會，在好幾年之前就知道設計模式。之前也一直抽時間學，但總是學了就忘。而且學習過程很枯燥，完全是背誦式的記憶那些類圖，不是真正的理解，更別提應用了。
設計，就是為了更好的應對變化。沒畢業時候不知道軟體系統怎麼會有變化，但是工作之後慢慢就會發現，變化，那叫乙個天馬行空。。。
一提到「設計」，大部分人可能會直接想到設計模式，而且是23種設計模式。其實這是錯誤的。其實學會設計、應用設計，應該分為四個層次：
首先要了解物件導向，什麼是物件導向？什麼是封裝、繼承和多型，以及三個特點的表現形式。基礎很重要。
要想充分了解物件導向，三個特點，最好還是按部就班的參考一本權威書籍，看看書上說的你是不是真的理解。看看繼承和多型的表現形式你是否都知道。
如果沒按部就班看過書，就不要以為自己都會了。借用某相聲演員一句話：「你以為你以為的就是你以為的？」
如何更好的解決「變化」問題？答案是「提取抽象、隔離具體」。
什麼是「抽象」？ 抽象就是不變的東西，乙個資料表的操作，總會有增刪改查，把他們作為介面，這是不變的。
什麼是「具體」？ 具體是實際執行的，乙個資料表的增刪改查，用sqlserver、access還是oracle？可能會有變化。
我們應該依賴於抽象程式設計，而不是依賴於具體程式設計。應該把程式中的共性抽象出來，並且把具體實現的部分隔離開來，讓他們都依賴於抽象，並且互不影響。這其實就是設計。
只有理解了「抽象」、「具體」、「隔離」這幾個詞兒，你才能真正理解設計模式。否則就別指望。
系統設計的5大原則，簡寫分別是s、o、l、i、d。
對於以上5大原則，此處不詳細解釋，有興趣的可以查閱《你必須知道的.net》第二版，裡面講的非常詳細。
如果詳細分析這5大原則，其實他們都是圍繞著「提取抽象、隔離具體」來的。
最後才是設計模式，設計模式其實是一些工具而已。
是「術」，不是「道」。如果你不明白以上那些「道」，而直接去學「術」，肯定是學一次忘一次。
在看每個設計模式的時候，你都要去向著這個方向去思考：它是不是提取了抽象、分離了具體、依賴於抽象、封裝了具體？ 這樣一來，你就會明白了。
工廠模式在設計模式中分三種：簡單工廠、工廠方法和抽象工廠，其實這三種對應了不同的抽象程度。 下面簡單分析前兩種。
看上圖，很明顯是「提取抽象，分離具體」。將資料操作的介面提取出來，交給不同的實現類來實現。
工廠類返回的是idbhelper介面，即客戶端會呼叫idbhelper介面，而不需要關心具體實現，這就是「依賴於抽象，而不是依賴於具體」。
還符合「開放封閉原則」，例如現在又要用db2資料庫，那麼再加乙個實現類就行，無需改其他地方。客戶端也不會察覺後台的變化。這就是：對擴充套件開放，對修改封閉。
簡單工廠之所以叫「簡單」，是因為它的工廠類還依賴於資料操作實現類，這違反了「依賴倒置原則」，那麼該怎麼辦呢？
上文說了，簡單工廠類依賴與資料操作實現類，當前有3個實現類，那麼工廠類肯定需要判斷，免不了有if else或者swicth case語句，
switch (type)
如何讓工廠類不依賴於資料操作實現類？ 答案還是「提取抽象，分離具體實現」。
將工廠類的具體職責抽象出來，然後分離一些實現類，分別實現各自的功能。
學設計模式不容易，需要熟悉語言、物件導向、理解設計原則。。。。即便是都看會了，理解了，到了應用又是個麻煩事兒。
有一位大牛說過：《設計模式》這本書，我們要像字典一樣經常拿出來翻翻看看，而不是通篇看完就算了。
可見，它需要我們長期的「學習 - 應用 - 總結 - 學習」，才能更好的理解。
另外，我感覺在系統設計中，也沒有必要非得去套用設計模式，只要符合設計原則，符合開發、執行效率，怎樣設計都行，不要為了用而用，濫用不如不用。
話又說回來，還是對設計大原則，對「道」的理解。
學習設計模式前明確的幾個問題
就是 設計的一種模式。好吧，看上去像是一句廢話。我們編碼的目的自然是為了實現特定的需求，某種意義上講，只要需求實現了，我們就達到了目的。但事實上，在實際應用中，需求是多變的，甚至編碼的人員也是多變的，這就帶來了一些功能的拓展，運維接手的難易程度。良好的程式設計習慣可以給我們帶來很大便捷，具體請見阿里...
學習CSS必讀
發展過程 版本 說明css1 1995年12月，層疊樣式表的第乙份正式標準 csscading style sheets level 1 完成，稱為w3c的推薦標準 css2 1997年初，w3c組織負責css的工作組開始討論第一版中沒有涉及到的問題。其中討論結果組成了1998年5月出版的css規範...
學習設計模式 原型設計模式
先想一下既然要建立新的例項，為什麼不直接使用 new 而要設計出乙個原型模式進行例項的複製呢？這是因為 有的時候，我們也會在不指定類名的前提下生成例項，例如像圖形編輯器中拖動現有的模型工具製作圖形的例項，這種是非常典型的生成例項的過程太過複雜，很難根據類來生成例項場景，因此需要根據現有的例項來生成新...