初中級程序員怎樣才能輕松快速的理解設(shè)計模式

最近發(fā)現(xiàn)關(guān)于設(shè)計模式這一塊，大家關(guān)注度挺高的。沒錯，其實我也覺得設(shè)計模式是區(qū)分程序員與架構(gòu)師的重要標準，可以說設(shè)計模式是架構(gòu)是必須掌握的基礎(chǔ)。但是，對于我們普普通通的程序員來說，即使我們不會去寫底層的代碼，設(shè)計底層框架，但是如果我們深刻的理解了這些常用的設(shè)計模式，以后開發(fā)項目，如果遇到某些復(fù)雜需求，我們不妨這些角度想一想問題，說不定很快會找到思路，而且，現(xiàn)在很多公司都用自己的框架，如果我們理解了，再去研究公司自己的框架，會很輕松的。最近，忙于找工作，閑余時我看了本《設(shè)計模式精解》的書，又從網(wǎng)上學(xué)習(xí)了一下，體會很深，在這里，我想給大家分享一下。

關(guān)于設(shè)計模式的理解-----先看這個，理解是什么東西再看下面

說到設(shè)計模式，字面意思就是項目設(shè)計的模式，我第一次看，頭也大，感覺什么也看不懂，不是我現(xiàn)有能力看的東西。其實，你應(yīng)該這樣理解，設(shè)計模式并不是那么讓人害怕的。這就是那些牛人經(jīng)過無數(shù)次的開發(fā)，無數(shù)次的需求變化然后不斷的進行的代碼重構(gòu)（封裝等）,慢慢的總結(jié)出來的，然后，他覺得不錯，給大家分享后，慢慢的很多人遇到這種需求都嘗試采用他的這種解決思路，而后，這種固定的解決思路便被人成為一種模式。其實，當我們在和客戶交流過程中，會發(fā)現(xiàn)客戶的需求總是不完整的，有時候可能也是錯誤的，需求不會說明全部的情況，面對這樣的問題，我們就會想能不能通過接口、抽象類等實現(xiàn)一種通用的解決方式，能夠根據(jù)需求的變化，不會觸動底層的東西，只要修改或者添加少量的代碼就能解決問題，而且修改的代碼量越少越好，當然，這正好符合人們常說的“高內(nèi)聚，低耦合”的原則。

常用的幾種設(shè)計模式的理解-------這是重頭戲��！只是個人看法，理解了才能用，理解萬歲！

抽象工廠模式

需求問題：為特定的客戶需求或者情況提供特定系列的接口實現(xiàn)（類似工廠針對某類需求新建部門）

意圖：一系列的對象需要被實例化

效果：該模式將使用哪些對象與如何使用這些對象的邏輯想隔離

實現(xiàn)：定義一個抽象類來指定哪些對象要被創(chuàng)建，然后為每個對象具體實現(xiàn)

單例模式

需求問題：不同的客戶對象需要引用同一個對象，你必須確保自己擁有的這個對象有且只有一個

意圖：你需要只創(chuàng)建和使用唯一的一個對象，不需要全局的對象來控制它的實例化

效果：客戶不需要關(guān)心是否有其它實例存在，這是在它內(nèi)部實現(xiàn)的

詳細實例：http://www.cnblogs.com/xun126/archive/2011/03/09/1970807.html

適配器模式

需求問題：一個系統(tǒng)擁有正確的數(shù)據(jù)和行為，但是接口是錯誤的，實現(xiàn)不了全部的方法

意圖：將一個無法控制的接口實現(xiàn)對象與一個自定的接口相匹配，從而在不影響該實現(xiàn)對象的接口的情況下，可以擴充方法（引用另一接口的實現(xiàn)中的方法）

效果：通過定義另外的接口并實現(xiàn)，并引用到現(xiàn)有的接口實現(xiàn)中，讓其不受原有接口的限制，擴充方法，打破原有接口的局限性，適應(yīng)新的類結(jié)構(gòu)

實現(xiàn)：將現(xiàn)存的類包含在另外一個類中，包容類與需要的接口相匹配，并調(diào)用被包容類的方法

此外，也可以和其它的抽象類進行適配

橋接模式

需求問題：一個抽象類的派生類必須使用多種實現(xiàn)部分，但是又不能造成類爆炸等問題

意圖：將一組實現(xiàn)部分從另一組使用它們的對象中分離出來

效果：實現(xiàn)部分與使用它的對象相分離，客戶不需要了解實現(xiàn)問題

實現(xiàn)：為所有的實現(xiàn)部分定義一個接口，讓抽象類的所有派生類使用這個接口

此外，注意過度的使用繼承，容易造成類爆炸

觀察者模式(報紙--訂閱者)

需求問題：當某個事件發(fā)生時，你需要向一系列的對象發(fā)出通知，而這些對象是不斷變化的

意圖：在對象之間定義一種一對多的依賴關(guān)系，當一個對象的狀態(tài)發(fā)生改變，所有依賴它的對象都將會的到通知并自動更新

詳細實例：http://www.cnblogs.com/circleLee/archive/2011/07/21/2112912.html

裝飾者模式

需求問題：附加功能時，可能出現(xiàn)在對象基礎(chǔ)功能（創(chuàng)建）之前或之后

意圖：為一個對象動態(tài)鏈接附加職責(zé)（動態(tài)的增加功能）

實現(xiàn)：創(chuàng)建一個抽象類來表示原始的類和要添加到這個類上的新功能。在裝飾者類中，將對新功能的調(diào)用放到對象調(diào)用之前或之后

外觀模式

需求問題：只需要使用一個復(fù)雜系統(tǒng)的子系統(tǒng)，或者需要一種特殊的方式與系統(tǒng)交互

意圖：希望簡化現(xiàn)有系統(tǒng)的使用方法

效果：該模式簡化了對所需子系統(tǒng)的使用，但是，由于是子系統(tǒng)，所以系統(tǒng)的某些功能對客戶不能開放

實現(xiàn)：定義一個或一組新的類來提供所需的接口；讓新的類使用現(xiàn)有的系統(tǒng)

此外，外觀模式也可以用來隱藏和包裝原有的系統(tǒng)，方便跟蹤和監(jiān)視客戶對原有系統(tǒng)的使用，以及改變我們原有的系統(tǒng)，實現(xiàn)和新系統(tǒng)的切換

小結(jié)

以上模式介紹的可能不是太多，最主要讓大家理解。如果大家還是不太理解，下次我給大家找些例子看看，建議多找?guī)妆具@樣的書好好看看，最主要的是在以后項目中要多用，多

練，至少要多去接觸，用的時間長了，你會理解更深，才叫真正的掌握，最好形成自己的一套開發(fā)風(fēng)格。謝謝了！