以下如果我有說錯的或者不到位的地方，請大牛們指出來，不要讓我誤人子弟奧！大家一起來交流學習！
博文前言 ----和大家嘮叨嘮叨，不要煩奧
最近發現關於設計模式這一塊，大家關注度挺高的。沒錯，其實我也覺得設計模式是區分程序員與架構師的重要標准，可以說設計模式是架構是必須掌握的基礎。但是，對於我們普普通通的程序員來說，即使我們不會去寫底層的代碼，設計底層框架，但是如果我們深刻的理解了這些常用的設計模式，以后開發項目，如果遇到某些復雜需求，我們不妨這些角度想一想問題，說不定很快會找到思路，而且，現在很多公司都用自己的框架，如果我們理解了，再去研究公司自己的框架，會很輕松的。最近，忙於找工作，閑余時我看了本《設計模式精解》的書，又從網上學習了一下，體會很深，在這里，我想給大家分享一下。
關於設計模式的理解-----先看這個，理解是什么東西再看下面
說到設計模式，字面意思就是項目設計的模式，我第一次看，頭也大，感覺什么也看不懂，不是我現有能力看的東西。其實，你應該這樣理解，設計模式並不是那么讓人害怕的。這就是那些牛人經過無數次的開發，無數次的需求變化然后不斷的進行的代碼重構（封裝等）,慢慢的總結出來的，然后，他覺得不錯，給大家分享后，慢慢的很多人遇到這種需求都嘗試采用他的這種解決思路，而后，這種固定的解決思路便被人成為一種模式。其實，當我們在和客戶交流過程中，會發現客戶的需求總是不完整的，有時候可能也是錯誤的，需求不會說明全部的情況，面對這樣的問題，我們就會想能不能通過接口、抽象類等實現一種通用的解決方式，能夠根據需求的變化，不會觸動底層的東西，只要修改或者添加少量的代碼就能解決問題，而且修改的代碼量越少越好，當然，這正好符合人們常說的“高內聚，低耦合”的原則。
常用的幾種設計模式的理解-------這是重頭戲啊！只是個人看法，理解了才能用，理解萬歲！
抽象工廠模式
需求問題：為特定的客戶需求或者情況提供特定系列的接口實現（類似工廠針對某類需求新建部門）
意圖：一系列的對象需要被實例化
效果：該模式將使用哪些對象與如何使用這些對象的邏輯想隔離
實現：定義一個抽象類來指定哪些對象要被創建，然后為每個對象具體實現
單例模式
需求問題：不同的客戶對象需要引用同一個對象，你必須確保自己擁有的這個對象有且只有一個
意圖：你需要只創建和使用唯一的一個對象，不需要全局的對象來控制它的實例化
效果：客戶不需要關心是否有其它實例存在，這是在它內部實現的
詳細實例：http://www.cnblogs.com/xun126/archive/2011/03/09/1970807.html
適配器模式
需求問題：一個系統擁有正確的數據和行為，但是接口是錯誤的，實現不了全部的方法
意圖：將一個無法控制的接口實現對象與一個自定的接口相匹配，從而在不影響該實現對象的接口的情況下，可以擴充方法（引用另一接口的實現中的方法）
效果：通過定義另外的接口並實現，並引用到現有的接口實現中，讓其不受原有接口的限制，擴充方法，打破原有接口的局限性，適應新的類結構
實現：將現存的類包含在另外一個類中，包容類與需要的接口相匹配，並調用被包容類的方法
此外，也可以和其它的抽象類進行適配
橋接模式
需求問題：一個抽象類的派生類必須使用多種實現部分，但是又不能造成類爆炸等問題
意圖：將一組實現部分從另一組使用它們的對象中分離出來
效果：實現部分與使用它的對象相分離，客戶不需要了解實現問題
實現：為所有的實現部分定義一個接口，讓抽象類的所有派生類使用這個接口
此外，注意過度的使用繼承，容易造成類爆炸
觀察者模式(報紙--訂閱者)
需求問題：當某個事件發生時，你需要向一系列的對象發出通知，而這些對象是不斷變化的
意圖：在對象之間定義一種一對多的依賴關系，當一個對象的狀態發生改變，所有依賴它的對象都將會的到通知並自動更新
詳細實例：http://www.cnblogs.com/circleLee/archive/2011/07/21/2112912.html
裝飾者模式
需求問題：附加功能時，可能出現在對象基礎功能（創建）之前或之后
意圖：為一個對象動態鏈接附加職責（動態的增加功能）
實現：創建一個抽象類來表示原始的類和要添加到這個類上的新功能。在裝飾者類中，將對新功能的調用放到對象調用之前或之后
外觀模式
需求問題：只需要使用一個復雜系統的子系統，或者需要一種特殊的方式與系統交互
意圖：希望簡化現有系統的使用方法
效果：該模式簡化了對所需子系統的使用，但是，由於是子系統，所以系統的某些功能對客戶不能開放
實現：定義一個或一組新的類來提供所需的接口；讓新的類使用現有的系統
此外，外觀模式也可以用來隱藏和包裝原有的系統，方便跟蹤和監視客戶對原有系統的使用，以及改變我們原有的系統，實現和新系統的切換
小結
以上模式介紹的可能不是太多，最主要讓大家理解。如果大家還是不太理解，下次我給大家找些例子看看，建議多找幾本這樣的書好好看看，最主要的是在以后項目中要多用，多
練，至少要多去接觸，用的時間長了，你會理解更深，才叫真正的掌握，最好形成自己的一套開發風格。謝謝了！