關於gof提到的23種設計模式前面的博文幾乎全都涉及到了，只是根據我們實際開發中使用的頻率不同，我的側重點也有所不同。學完這些所有的設計模式之後，我也有一些自己的心得體會，下面簡單的來說一說。
學習過程中了解到了設計模式有八大原則：依賴倒置原則，開放封閉原則，單一職責原則，liskov替換原則，介面隔離原則，物件組合優於類繼承，封裝變化點，面向介面程式設計。這些原則有些很抽象，有些很具體，具體的東西很好理解，抽象的東西只有深入了解每個設計模式之後才能知道它的含義。其實個人覺得我們在實際編寫**的過程中不需要特意地去關注這些原則，就像我前面的博文中提到的那樣，只要能夠分清楚**中穩定的和變化的部分，這就是乙個很好的開始。然後我們再從穩定部分中提取到乙個合適的介面用來應對未來可能發生的變化，這樣就是乙個好的設計了。至於你的設計有沒有符合這八大原則、屬不屬於23種經典設計模式之一，這些都不重要。重要的是這個設計能夠很好的解決當下的問題，並且能夠應對未來可能的變化這樣就夠了。
說說,學完設計模式之後，我覺得很重要的一些感悟（其實有些已經包含在那八大原則之內了）：
1，如果寫**的過程中不能明確怎樣做才最好，那就先寫出來，後面再重構。並不是每個人都是大牛，都能在開始開發之前就預想到了所有的可能，只有先寫出來，才能再後面重構的時候找到自己的不足並改正。
2，找到**中穩定的部分和變化的部分。把穩定的部分提取出來，變為基類（抽象化），並提供可供變化的介面（虛函式）以應對未來可能的變化。
3，能包含另外乙個類的指標就別用繼承。
4，兩個類或者多個類之間的關係如果太過緊耦合，就想辦法使其變為松耦合。（加乙個中間類）
5，乙個類不能設計的太過複雜，如果功能太多，就把它們拆分開。
用一些很簡單的**來說明就是下面的樣子。
//找到穩定部分，使其變為虛基類
class a
;//把變化都留到未來
class a1 :public class a ;
class a2 :public class a ;
...//應對變化吧
class b
;//如果再複雜一點，class b也可以設計成虛基類
1，單例模式。這個不用說，太經典了
2，模板方法。當你想設計乙個步驟或者說框架給別人用時，可能會需要它。
3，策略模式。當你的**中有大量的if/else或者switch/case時，並且在未來這條件變數會經常變動時，試試策略模式吧。
4，觀察者模式。非常重要，它很好的解決了我們程式中各個物件的訊息通訊問題。
5，橋接模式。當你的類設計的過於臃腫的時候，想想看是不是可以拆開來看看。
6，工廠方法和抽象工廠。建立多個物件時很好的選擇。
7，享元模式。它的思想在物件池、執行緒池中有很好的體現。
8，介面卡模式。改造老的類，以適應新的變化。
9，**模式。別人寫的好東西，拿來自己用用。
10，組合模式。它的思想在一些gui設計中會經常看到。
最後，希望自己在以後的工作中能夠做到「手中無劍，心中有劍」！
PHP PDO 心得體會
關於pdo 我想可以不用做過多的描述，寫一寫最近的使用心得體會 首先 關於如何使用pdo 連線到資料庫 dbms mysql 使用的資料庫 host localhost 選擇的主機 dbname test 選擇的資料庫 user root 登陸的使用者名稱 password 使用者密碼 dsn dm...
銷售心得體會
銷售思維的培養 1.裝可憐讓客戶動惻隱之心是一種方法但是不適合男人 2.身處高位的銷售領導往往擁有給客戶的折扣和動用資源的優勢，不要當綠葉，要按兵不動尋找時機 3.市場上的大客戶與哪家合作就會成為標桿事件，哪家公司就會成為一線公司。4.站在客戶的角度，在業務上給予中肯的意見，得到客戶的感謝和認可。5...
面試心得體會
最近開發人手短缺成了大問題，因此招人也成了乙個重要任務。通過這幾天的面試，對這方面有了一些心得體會。一是it企業需要哪方面素質的人才。我感覺關鍵有兩條，一是能幹活，二是能合作。企業為什麼青睞有經驗的人？因為來了就能幹活。當然對於學生而言，經驗缺乏是一大缺陷，這就要展現另一方面 我具備成為幹活能手的能...