一、我們都知道設計經驗的重要價值。你曾經多少次有過這種感覺：你已經解決過了一個問題但就是不能確切知道是在什麼地方或怎麼解決的？如果你能記起以前問題的細節和怎麼解決它的，你就可以複用以前的經驗而不需要重新發現它。然而，我們並沒有很好記錄下可供他人使用的軟件設計經驗。如何將面向對象軟件的設計經驗記錄下來呢？設計模式這個概念的出現使我們能從思維上進行理論上系統的把握。
設計模式使人們可以更加簡單方便地複用成功的設計和體系結構。將已證實的技術表述成設計模式也會使新系統開發者更加容易理解其設計思路。
二、 至於什麼是設計模式呢？GoF在《設計模式》一書中將模式描述爲：在一定環境中解決某一問題的方案，包括三個基本元素--問題，解決方案和環境。同時也提出了一個記錄模式的模板，有興趣的讀者可以去讀該書（強烈建議初學者以該書作爲入門數目）。不過，就我個人簡單化的習慣的話，最爲常用而又最具有意義的就是：意圖、動機和適用。這三個方面從實際入手把一個解決方案很好的描述出來，首先是爲了解決什麼問題，其次是怎樣解決問題，最後是現實的實用性。
以下我對怎樣學習設計模式的建議：
1）熟悉C++的讀者，可以去參考GoF的《設計模式》一書，該書可以說是設計模式教材的鼻祖，以後很多教材都是參考這本書的，是入門的必讀之作。熟悉Java的人可以去參考另外一本書：James W. Cooper的Design Patterns,該書好像沒有中文版。
2）其次，在學習過程中，要從解決的問題與環境入手，因爲設計模式主要是針對解決方案的。只有到了具體的實例中，具體的設計模式纔有相應的代碼。同時在學習過程中，最好使用兩種以上的語言來實現該模式，這樣，就可以通過比較來掌握該種情況下如何通過代碼來實現，掌握該種情況下的模式怎樣實現。所以，最好掌握了C++和Java，然後在學習模式過程中不斷的練習。
3）要有目的的學習。在實際工作中，當遇到了某種問題已經解決的時候，要總結自己的經驗，同時要把這種經驗用設計模式表達出來，這樣，以後再次遇到該問題的時候，由於頭腦已經有這種模式的思想存在，就能迅速的解決問題了。或者看別人的源代碼時，遇到很好的解決方案時，要注意總結，形成自己的設計模式。一句話，只有不斷的學習才能最大的成功。
4）最重要的一點，不要老是抱着設計模式的概念不放。GoF的<<設計模式>>一書提出了基本的23種設計模式，但這些設計模式到了實際的應用中千變萬化，不可能全部把握，只要記住一點，萬變不離其宗。設計模式的意義在於有一個具體的概念來把我們的經驗總結，而不是爲了模式而學習模式，應該是爲了具體的方案來學習模式。只有這樣，你纔不會被那些千變萬化的模式迷惑自己。
最後，我想提出的一點是，平時要多想想，多動一下腦筋，總結自己的經驗，這樣的話，我們的代碼生活也許會變得更加有趣。
三、以下是一些具體實用的概念：
1、先提一個我們怎樣組織對象之間關係的概念。DI(Dependency Injection)：依賴注入，以前有個叫法是IoC，通俗的說就是使用library code調用user code，而不是傳統的使用用戶的代碼來調用library code。通常是通過Template Method模式或者Strategy模式來實現。把具體的步驟封裝在基類中，而具體的實現算法在子類實現。IoC是框架實現的基礎，Martin Fowler在Inversion of Control Containers and the Dependency Injection pattern一書中詳細解釋了什麼是依賴注入。這個概念爲我們瞭解對象之間的關係和怎樣在具體代碼中實現這些關聯很有幫助。事實上，這個概念主要實現容器方便化的配置與更好的軟件複用，同時減輕了組件之間的依賴關係，同時也大大提高了組件的可移植性，這意味着，組件得到重用的機會將會更多。熟悉j2ee的讀者應該明白這種意思，spring框架就是一個很好的使用了DI的一個框架與容器。這裏把這個概念最爲片面簡單化，用這個概念來表達怎樣瞭解對象之間的關係，以下爲依賴注入的幾種實現類型（也是在這裏爲什麼介紹DI的原因）：
1）接口注入：我們通常藉助接口來將調用者與實現者分離。在運行期，容器可以通過dynamic_cast來把接口的實現（或者說是子類）把具體的實現注入該實例中。我們在平時編程時，經常想到的是使用該種方法來建立類之間的關係。
2）設值注入：這在java中很常見，同時也很直觀、自然。JavaBean對屬性的存取中的思想也是通過這樣實現，通過一系列的setter和getter方法來實現。在c++中，這種方法也常見，通常是聲明一個私有的成員變量，該變量是指向某對象的指針，類通過提供一個公有方法來訪問該對象即可。而在DI中，這種模型得到了最廣泛的應用（如spring框架中）
3）構造器注入：通過在構造函數中聲明對其他對象的引用來實現，這種方法在c++中比較常見一點。這種方法避免了繁瑣的setter方法（這個問題一般IDE都替我們解決），同時因爲少了setter方法，無需擔心上層代碼調用setter方法造成的影響。通過構造子注入，意味着我們可以在構造函數中決定依賴關係的注入順序，對於一個大量依賴外部服務的組件而言，依賴關係的獲得順序可能非常重要。
