一、什么是設(shè)計(jì)模式

設(shè)計(jì)模式（Design pattern）是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過(guò)分類(lèi)編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無(wú)疑問(wèn)，設(shè)計(jì)模式于己于他人于系統(tǒng)都是多贏的，設(shè)計(jì)模式使代碼編制真正工程化，設(shè)計(jì)模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項(xiàng)目中合理的運(yùn)用設(shè)計(jì)模式可以完美的解決很多問(wèn)題，每種模式在現(xiàn)在中都有相應(yīng)的原理來(lái)與之對(duì)應(yīng)，每一個(gè)模式描述了一個(gè)在我們周?chē)粩嘀貜?fù)發(fā)生的問(wèn)題，以及該問(wèn)題的核心解決方案，這也是它能被廣泛應(yīng)用的原因。簡(jiǎn)單說(shuō)：

模式：在某些場(chǎng)景下，針對(duì)某類(lèi)問(wèn)題的某種通用的解決方案。

場(chǎng)景：項(xiàng)目所在的環(huán)境

問(wèn)題：約束條件，項(xiàng)目目標(biāo)等

解決方案：通用、可復(fù)用的設(shè)計(jì)，解決約束達(dá)到目標(biāo)。

二、設(shè)計(jì)模式的三個(gè)分類(lèi)

創(chuàng)建型模式：對(duì)象實(shí)例化的模式，創(chuàng)建型模式用于解耦對(duì)象的實(shí)例化過(guò)程。

結(jié)構(gòu)型模式：把類(lèi)或?qū)ο蠼Y(jié)合在一起形成一個(gè)更大的結(jié)構(gòu)。

行為型模式：類(lèi)和對(duì)象如何交互，及劃分責(zé)任和算法。

如下圖所示：

三、各分類(lèi)中模式的關(guān)鍵點(diǎn)

單例模式：某個(gè)類(lèi)只能有一個(gè)實(shí)例，提供一個(gè)全局的訪(fǎng)問(wèn)點(diǎn)。

簡(jiǎn)單工廠(chǎng)：一個(gè)工廠(chǎng)類(lèi)根據(jù)傳入的參量決定創(chuàng)建出那一種產(chǎn)品類(lèi)的實(shí)例。

工廠(chǎng)方法：定義一個(gè)創(chuàng)建對(duì)象的接口，讓子類(lèi)決定實(shí)例化那個(gè)類(lèi)。

抽象工廠(chǎng)：創(chuàng)建相關(guān)或依賴(lài)對(duì)象的家族，而無(wú)需明確指定具體類(lèi)。

建造者模式：封裝一個(gè)復(fù)雜對(duì)象的構(gòu)建過(guò)程，并可以按步驟構(gòu)造。

原型模式：通過(guò)復(fù)制現(xiàn)有的實(shí)例來(lái)創(chuàng)建新的實(shí)例。

適配器模式：將一個(gè)類(lèi)的方法接口轉(zhuǎn)換成客戶(hù)希望的另外一個(gè)接口。

組合模式：將對(duì)象組合成樹(shù)形結(jié)構(gòu)以表示“”部分-整體“”的層次結(jié)構(gòu)。

裝飾模式：動(dòng)態(tài)的給對(duì)象添加新的功能。

代理模式：為其他對(duì)象提供一個(gè)代理以便控制這個(gè)對(duì)象的訪(fǎng)問(wèn)。

亨元（蠅量）模式：通過(guò)共享技術(shù)來(lái)有效的支持大量細(xì)粒度的對(duì)象。

外觀(guān)模式：對(duì)外提供一個(gè)統(tǒng)一的方法，來(lái)訪(fǎng)問(wèn)子系統(tǒng)中的一群接口。

橋接模式：將抽象部分和它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立的變化。

模板模式：定義一個(gè)算法結(jié)構(gòu)，而將一些步驟延遲到子類(lèi)實(shí)現(xiàn)。

解釋器模式：給定一個(gè)語(yǔ)言，定義它的文法的一種表示，并定義一個(gè)解釋器。

策略模式：定義一系列算法，把他們封裝起來(lái)，并且使它們可以相互替換。

狀態(tài)模式：允許一個(gè)對(duì)象在其對(duì)象內(nèi)部狀態(tài)改變時(shí)改變它的行為。

觀(guān)察者模式：對(duì)象間的一對(duì)多的依賴(lài)關(guān)系。

備忘錄模式：在不破壞封裝的前提下，保持對(duì)象的內(nèi)部狀態(tài)。

中介者模式：用一個(gè)中介對(duì)象來(lái)封裝一系列的對(duì)象交互。

命令模式：將命令請(qǐng)求封裝為一個(gè)對(duì)象，使得可以用不同的請(qǐng)求來(lái)進(jìn)行參數(shù)化。

訪(fǎng)問(wèn)者模式：在不改變數(shù)據(jù)結(jié)構(gòu)的前提下，增加作用于一組對(duì)象元素的新功能。

責(zé)任鏈模式：將請(qǐng)求的發(fā)送者和接收者解耦，使的多個(gè)對(duì)象都有處理這個(gè)請(qǐng)求的機(jī)會(huì)。

迭代器模式：一種遍歷訪(fǎng)問(wèn)聚合對(duì)象中各個(gè)元素的方法，不暴露該對(duì)象的內(nèi)部結(jié)構(gòu)。

四、概說(shuō)23種設(shè)計(jì)模式

1.單例模式

單例模式，它的定義就是確保某一個(gè)類(lèi)只有一個(gè)實(shí)例，并且提供一個(gè)全局訪(fǎng)問(wèn)點(diǎn)。

單例模式具備典型的3個(gè)特點(diǎn)：1、只有一個(gè)實(shí)例。2、自我實(shí)例化。3、提供全局訪(fǎng)問(wèn)點(diǎn)。

因此當(dāng)系統(tǒng)中只需要一個(gè)實(shí)例對(duì)象或者系統(tǒng)中只允許一個(gè)公共訪(fǎng)問(wèn)點(diǎn)，除了這個(gè)公共訪(fǎng)問(wèn)點(diǎn)外，不能通過(guò)其他訪(fǎng)問(wèn)點(diǎn)訪(fǎng)問(wèn)該實(shí)例時(shí)，可以使用單例模式。

單例模式的主要優(yōu)點(diǎn)就是節(jié)約系統(tǒng)資源、提高了系統(tǒng)效率，同時(shí)也能夠嚴(yán)格控制客戶(hù)對(duì)它的訪(fǎng)問(wèn)。也許就是因?yàn)橄到y(tǒng)中只有一個(gè)實(shí)例，這樣就導(dǎo)致了單例類(lèi)的職責(zé)過(guò)重，違背了“單一職責(zé)原則”，同時(shí)也沒(méi)有抽象類(lèi)，所以擴(kuò)展起來(lái)有一定的困難。其UML結(jié)構(gòu)圖非常簡(jiǎn)單，就只有一個(gè)類(lèi)，如下圖：

2.工廠(chǎng)方法模式

作為抽象工廠(chǎng)模式的孿生兄弟，工廠(chǎng)方法模式定義了一個(gè)創(chuàng)建對(duì)象的接口，但由子類(lèi)決定要實(shí)例化的類(lèi)是哪一個(gè)，也就是說(shuō)工廠(chǎng)方法模式讓實(shí)例化推遲到子類(lèi)。

工廠(chǎng)方法模式非常符合“開(kāi)閉原則”，當(dāng)需要增加一個(gè)新的產(chǎn)品時(shí)，我們只需要增加一個(gè)具體的產(chǎn)品類(lèi)和與之對(duì)應(yīng)的具體工廠(chǎng)即可，無(wú)須修改原有系統(tǒng)。同時(shí)在工廠(chǎng)方法模式中用戶(hù)只需要知道生產(chǎn)產(chǎn)品的具體工廠(chǎng)即可，無(wú)須關(guān)系產(chǎn)品的創(chuàng)建過(guò)程，甚至連具體的產(chǎn)品類(lèi)名稱(chēng)都不需要知道。雖然他很好的符合了“開(kāi)閉原則”，但是由于每新增一個(gè)新產(chǎn)品時(shí)就需要增加兩個(gè)類(lèi)，這樣勢(shì)必會(huì)導(dǎo)致系統(tǒng)的復(fù)雜度增加。其UML結(jié)構(gòu)圖：

3.抽象工廠(chǎng)模式

所謂抽象工廠(chǎng)模式就是提供一個(gè)接口，用于創(chuàng)建相關(guān)或者依賴(lài)對(duì)象的家族，而不需要明確指定具體類(lèi)。他允許客戶(hù)端使用抽象的接口來(lái)創(chuàng)建一組相關(guān)的產(chǎn)品，而不需要關(guān)系實(shí)際產(chǎn)出的具體產(chǎn)品是什么。這樣一來(lái)，客戶(hù)就可以從具體的產(chǎn)品中被解耦。它的優(yōu)點(diǎn)是隔離了具體類(lèi)的生成，使得客戶(hù)端不需要知道什么被創(chuàng)建了，而缺點(diǎn)就在于新增新的行為會(huì)比較麻煩，因?yàn)楫?dāng)添加一個(gè)新的產(chǎn)品對(duì)象時(shí)，需要更加需要更改接口及其下所有子類(lèi)。其UML結(jié)構(gòu)圖如下：

4.建造者模式

對(duì)于建造者模式而已，它主要是將一個(gè)復(fù)雜對(duì)象的構(gòu)建與表示分離，使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示。適用于那些產(chǎn)品對(duì)象的內(nèi)部結(jié)構(gòu)比較復(fù)雜。

建造者模式將復(fù)雜產(chǎn)品的構(gòu)建過(guò)程封裝分解在不同的方法中，使得創(chuàng)建過(guò)程非常清晰，能夠讓我們更加精確的控制復(fù)雜產(chǎn)品對(duì)象的創(chuàng)建過(guò)程，同時(shí)它隔離了復(fù)雜產(chǎn)品對(duì)象的創(chuàng)建和使用，使得相同的創(chuàng)建過(guò)程能夠創(chuàng)建不同的產(chǎn)品。但是如果某個(gè)產(chǎn)品的內(nèi)部結(jié)構(gòu)過(guò)于復(fù)雜，將會(huì)導(dǎo)致整個(gè)系統(tǒng)變得非常龐大，不利于控制，同時(shí)若幾個(gè)產(chǎn)品之間存在較大的差異，則不適用建造者模式，畢竟這個(gè)世界上存在相同點(diǎn)大的兩個(gè)產(chǎn)品并不是很多，所以它的使用范圍有限。其UML結(jié)構(gòu)圖：

5.原型模式

在我們應(yīng)用程序可能有某些對(duì)象的結(jié)構(gòu)比較復(fù)雜，但是我們又需要頻繁的使用它們，如果這個(gè)時(shí)候我們來(lái)不斷的新建這個(gè)對(duì)象勢(shì)必會(huì)大大損耗系統(tǒng)內(nèi)存的，這個(gè)時(shí)候我們需要使用原型模式來(lái)對(duì)這個(gè)結(jié)構(gòu)復(fù)雜又要頻繁使用的對(duì)象進(jìn)行克隆。所以原型模式就是用原型實(shí)例指定創(chuàng)建對(duì)象的種類(lèi)，并且通過(guò)復(fù)制這些原型創(chuàng)建新的對(duì)象。

它主要應(yīng)用與那些創(chuàng)建新對(duì)象的成本過(guò)大時(shí)。它的主要優(yōu)點(diǎn)就是簡(jiǎn)化了新對(duì)象的創(chuàng)建過(guò)程，提高了效率，同時(shí)原型模式提供了簡(jiǎn)化的創(chuàng)建結(jié)構(gòu)。UML結(jié)構(gòu)圖：

模式結(jié)構(gòu)
原型模式包含如下角色：
Prototype：抽象原型類(lèi)
ConcretePrototype：具體原型類(lèi)
Client：客戶(hù)類(lèi)

6.適配器模式

在我們的應(yīng)用程序中我們可能需要將兩個(gè)不同接口的類(lèi)來(lái)進(jìn)行通信，在不修改這兩個(gè)的前提下我們可能會(huì)需要某個(gè)中間件來(lái)完成這個(gè)銜接的過(guò)程。這個(gè)中間件就是適配器。所謂適配器模式就是將一個(gè)類(lèi)的接口，轉(zhuǎn)換成客戶(hù)期望的另一個(gè)接口。它可以讓原本兩個(gè)不兼容的接口能夠無(wú)縫完成對(duì)接。

作為中間件的適配器將目標(biāo)類(lèi)和適配者解耦，增加了類(lèi)的透明性和可復(fù)用性。

適配器模式包含如下角色：
Target：目標(biāo)抽象類(lèi)
Adapter：適配器類(lèi)
Adaptee：適配者類(lèi)
Client：客戶(hù)類(lèi)

7.橋接模式

如果說(shuō)某個(gè)系統(tǒng)能夠從多個(gè)角度來(lái)進(jìn)行分類(lèi)，且每一種分類(lèi)都可能會(huì)變化，那么我們需要做的就是講這多個(gè)角度分離出來(lái)，使得他們能獨(dú)立變化，減少他們之間的耦合，這個(gè)分離過(guò)程就使用了橋接模式。所謂橋接模式就是講抽象部分和實(shí)現(xiàn)部分隔離開(kāi)來(lái)，使得他們能夠獨(dú)立變化。

橋接模式將繼承關(guān)系轉(zhuǎn)化成關(guān)聯(lián)關(guān)系，封裝了變化，完成了解耦，減少了系統(tǒng)中類(lèi)的數(shù)量，也減少了代碼量。

橋接模式包含如下角色：
Abstraction：抽象類(lèi)
RefinedAbstraction：擴(kuò)充抽象類(lèi)
Implementor：實(shí)現(xiàn)類(lèi)接口
ConcreteImplementor：具體實(shí)現(xiàn)類(lèi)

8.組合模式

組合模式組合多個(gè)對(duì)象形成樹(shù)形結(jié)構(gòu)以表示“整體-部分”的結(jié)構(gòu)層次。它定義了如何將容器對(duì)象和葉子對(duì)象進(jìn)行遞歸組合，使得客戶(hù)在使用的過(guò)程中無(wú)須進(jìn)行區(qū)分，可以對(duì)他們進(jìn)行一致的處理。在使用組合模式中需要注意一點(diǎn)也是組合模式最關(guān)鍵的地方：葉子對(duì)象和組合對(duì)象實(shí)現(xiàn)相同的接口。這就是組合模式能夠?qū)⑷~子節(jié)點(diǎn)和對(duì)象節(jié)點(diǎn)進(jìn)行一致處理的原因。

雖然組合模式能夠清晰地定義分層次的復(fù)雜對(duì)象，也使得增加新構(gòu)件也更容易，但是這樣就導(dǎo)致了系統(tǒng)的設(shè)計(jì)變得更加抽象，如果系統(tǒng)的業(yè)務(wù)規(guī)則比較復(fù)雜的話(huà)，使用組合模式就有一定的挑戰(zhàn)了。

模式結(jié)構(gòu)
組合模式包含如下角色：
Component: 抽象構(gòu)件
Leaf: 葉子構(gòu)件
Composite: 容器構(gòu)件
Client: 客戶(hù)類(lèi)

9.裝飾模式

我們可以通過(guò)繼承和組合的方式來(lái)給一個(gè)對(duì)象添加行為，雖然使用繼承能夠很好擁有父類(lèi)的行為，但是它存在幾個(gè)缺陷：一、對(duì)象之間的關(guān)系復(fù)雜的話(huà)，系統(tǒng)變得復(fù)雜不利于維護(hù)。二、容易產(chǎn)生“類(lèi)爆炸”現(xiàn)象。三、是靜態(tài)的。在這里我們可以通過(guò)使用裝飾者模式來(lái)解決這個(gè)問(wèn)題。

裝飾者模式，動(dòng)態(tài)地將責(zé)任附加到對(duì)象上。若要擴(kuò)展功能，裝飾者提供了比繼承更加有彈性的替代方案。雖然裝飾者模式能夠動(dòng)態(tài)將責(zé)任附加到對(duì)象上，但是他會(huì)產(chǎn)生許多的細(xì)小對(duì)象，增加了系統(tǒng)的復(fù)雜度。

模式結(jié)構(gòu)
裝飾模式包含如下角色：
Component: 抽象構(gòu)件
ConcreteComponent: 具體構(gòu)件
Decorator: 抽象裝飾類(lèi)
ConcreteDecorator: 具體裝飾類(lèi)

10.外觀(guān)模式

我們都知道類(lèi)與類(lèi)之間的耦合越低，那么可復(fù)用性就越好，如果兩個(gè)類(lèi)不必彼此通信，那么就不要讓這兩個(gè)類(lèi)發(fā)生直接的相互關(guān)系，如果需要調(diào)用里面的方法，可以通過(guò)第三者來(lái)轉(zhuǎn)發(fā)調(diào)用。外觀(guān)模式非常好的詮釋了這段話(huà)。外觀(guān)模式提供了一個(gè)統(tǒng)一的接口，用來(lái)訪(fǎng)問(wèn)子系統(tǒng)中的一群接口。它讓一個(gè)應(yīng)用程序中子系統(tǒng)間的相互依賴(lài)關(guān)系減少到了最少，它給子系統(tǒng)提供了一個(gè)簡(jiǎn)單、單一的屏障，客戶(hù)通過(guò)這個(gè)屏障來(lái)與子系統(tǒng)進(jìn)行通信。通過(guò)使用外觀(guān)模式，使得客戶(hù)對(duì)子系統(tǒng)的引用變得簡(jiǎn)單了，實(shí)現(xiàn)了客戶(hù)與子系統(tǒng)之間的松耦合。但是它違背了“開(kāi)閉原則”，因?yàn)樵黾有碌淖酉到y(tǒng)可能需要修改外觀(guān)類(lèi)或客戶(hù)端的源代碼。

外觀(guān)模式包含如下角色：
Facade: 外觀(guān)角色
SubSystem:子系統(tǒng)角色

11.亨元模式

在一個(gè)系統(tǒng)中對(duì)象會(huì)使得內(nèi)存占用過(guò)多，特別是那些大量重復(fù)的對(duì)象，這就是對(duì)系統(tǒng)資源的極大浪費(fèi)。享元模式對(duì)對(duì)象的重用提供了一種解決方案，它使用共享技術(shù)對(duì)相同或者相似對(duì)象實(shí)現(xiàn)重用。享元模式就是運(yùn)行共享技術(shù)有效地支持大量細(xì)粒度對(duì)象的復(fù)用。系統(tǒng)使用少量對(duì)象,而且這些都比較相似，狀態(tài)變化小，可以實(shí)現(xiàn)對(duì)象的多次復(fù)用。這里有一點(diǎn)要注意：享元模式要求能夠共享的對(duì)象必須是細(xì)粒度對(duì)象。享元模式通過(guò)共享技術(shù)使得系統(tǒng)中的對(duì)象個(gè)數(shù)大大減少了，同時(shí)享元模式使用了內(nèi)部狀態(tài)和外部狀態(tài)，同時(shí)外部狀態(tài)相對(duì)獨(dú)立，不會(huì)影響到內(nèi)部狀態(tài)，所以享元模式能夠使得享元對(duì)象在不同的環(huán)境下被共享。同時(shí)正是分為了內(nèi)部狀態(tài)和外部狀態(tài)，享元模式會(huì)使得系統(tǒng)變得更加復(fù)雜，同時(shí)也會(huì)導(dǎo)致讀取外部狀態(tài)所消耗的時(shí)間過(guò)長(zhǎng)。

享元模式包含如下角色：
Flyweight: 抽象享元類(lèi)
ConcreteFlyweight: 具體享元類(lèi)
UnsharedConcreteFlyweight: 非共享具體享元類(lèi)
FlyweightFactory: 享元工廠(chǎng)類(lèi)

12.代理模式

代理模式就是給一個(gè)對(duì)象提供一個(gè)代理，并由代理對(duì)象控制對(duì)原對(duì)象的引用。它使得客戶(hù)不能直接與真正的目標(biāo)對(duì)象通信。代理對(duì)象是目標(biāo)對(duì)象的代表，其他需要與這個(gè)目標(biāo)對(duì)象打交道的操作都是和這個(gè)代理對(duì)象在交涉。

代理對(duì)象可以在客戶(hù)端和目標(biāo)對(duì)象之間起到中介的作用，這樣起到了的作用和保護(hù)了目標(biāo)對(duì)象的，同時(shí)也在一定程度上面減少了系統(tǒng)的耦合度。

代理模式包含如下角色：
oSubject: 抽象主題角色
oProxy: 代理主題角色
oRealSubject: 真實(shí)主題角色

13.訪(fǎng)問(wèn)者模式

訪(fǎng)問(wèn)者模式俗稱(chēng)23大設(shè)計(jì)模式中最難的一個(gè)。除了結(jié)構(gòu)復(fù)雜外，理解也比較難。在我們軟件開(kāi)發(fā)中我們可能會(huì)對(duì)同一個(gè)對(duì)象有不同的處理，如果我們都做分別的處理，將會(huì)產(chǎn)生災(zāi)難性的錯(cuò)誤。對(duì)于這種問(wèn)題，訪(fǎng)問(wèn)者模式提供了比較好的解決方案。訪(fǎng)問(wèn)者模式即表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中的各元素的操作，它使我們可以在不改變各元素的類(lèi)的前提下定義作用于這些元素的新操作。

訪(fǎng)問(wèn)者模式的目的是封裝一些施加于某種數(shù)據(jù)結(jié)構(gòu)元素之上的操作，一旦這些操作需要修改的話(huà)，接受這個(gè)操作的數(shù)據(jù)結(jié)構(gòu)可以保持不變。為不同類(lèi)型的元素提供多種訪(fǎng)問(wèn)操作方式，且可以在不修改原有系統(tǒng)的情況下增加新的操作方式。同時(shí)我們還需要明確一點(diǎn)那就是訪(fǎng)問(wèn)者模式是適用于那些數(shù)據(jù)結(jié)構(gòu)比較穩(wěn)定的，因?yàn)樗菍?shù)據(jù)的操作與數(shù)據(jù)結(jié)構(gòu)進(jìn)行分離了，如果某個(gè)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)相對(duì)穩(wěn)定，但是操作算法易于變化的話(huà)，就比較適用適用訪(fǎng)問(wèn)者模式，因?yàn)樵L(fǎng)問(wèn)者模式使得算法操作的增加變得比較簡(jiǎn)單了。

訪(fǎng)問(wèn)者模式包含如下角色：
Vistor: 抽象訪(fǎng)問(wèn)者
ConcreteVisitor: 具體訪(fǎng)問(wèn)者
Element: 抽象元素
ConcreteElement: 具體元素
ObjectStructure: 對(duì)象結(jié)構(gòu)

14.模板模式

有些時(shí)候我們做某幾件事情的步驟都差不多，僅有那么一小點(diǎn)的不同，在軟件開(kāi)發(fā)的世界里同樣如此，如果我們都將這些步驟都一一做的話(huà)，費(fèi)時(shí)費(fèi)力不討好。所以我們可以將這些步驟分解、封裝起來(lái)，然后利用繼承的方式來(lái)繼承即可，當(dāng)然不同的可以自己重寫(xiě)實(shí)現(xiàn)嘛！這就是模板方法模式提供的解決方案。

所謂模板方法模式就是在一個(gè)方法中定義一個(gè)算法的骨架，而將一些步驟延遲到子類(lèi)中。模板方法使得子類(lèi)可以在不改變算法結(jié)構(gòu)的情況下，重新定義算法中的某些步驟。

模板方法模式就是基于繼承的代碼復(fù)用技術(shù)的。在模板方法模式中，我們可以將相同部分的代碼放在父類(lèi)中，而將不同的代碼放入不同的子類(lèi)中。也就是說(shuō)我們需要聲明一個(gè)抽象的父類(lèi)，將部分邏輯以具體方法以及具體構(gòu)造函數(shù)的形式實(shí)現(xiàn)，然后聲明一些抽象方法讓子類(lèi)來(lái)實(shí)現(xiàn)剩余的邏輯，不同的子類(lèi)可以以不同的方式來(lái)實(shí)現(xiàn)這些邏輯。所以模板方法的模板其實(shí)就是一個(gè)普通的方法，只不過(guò)這個(gè)方法是將算法實(shí)現(xiàn)的步驟封裝起來(lái)的。

模板方法模式包含如下角色：
AbstractClass: 抽象類(lèi)
ConcreteClass: 具體子類(lèi)

15.策略模式

我們知道一件事可能會(huì)有很多種方式來(lái)實(shí)現(xiàn)它，但是其中總有一種最高效的方式，在軟件開(kāi)發(fā)的世界里面同樣如此，我們也有很多中方法來(lái)實(shí)現(xiàn)一個(gè)功能，但是我們需要一種簡(jiǎn)單、高效的方式來(lái)實(shí)現(xiàn)它，使得系統(tǒng)能夠非常靈活，這就是策略模式。

所以策略模式就是定義了算法族，分別封裝起來(lái)，讓他們之前可以互相轉(zhuǎn)換，此模式然該算法的變化獨(dú)立于使用算法的客戶(hù)。

在策略模式中它將這些解決問(wèn)題的方法定義成一個(gè)算法群，每一個(gè)方法都對(duì)應(yīng)著一個(gè)具體的算法，這里的一個(gè)算法我就稱(chēng)之為一個(gè)策略。雖然策略模式定義了算法，但是它并不提供算法的選擇，即什么算法對(duì)于什么問(wèn)題最合適這是策略模式所不關(guān)心的，所以對(duì)于策略的選擇還是要客戶(hù)端來(lái)做?？蛻?hù)必須要清楚的知道每個(gè)算法之間的區(qū)別和在什么時(shí)候什么地方使用什么策略是最合適的，這樣就增加客戶(hù)端的負(fù)擔(dān)。

同時(shí)策略模式也非常完美的符合了“開(kāi)閉原則”，用戶(hù)可以在不修改原有系統(tǒng)的基礎(chǔ)上選擇算法或行為，也可以靈活地增加新的算法或行為。但是一個(gè)策略對(duì)應(yīng)一個(gè)類(lèi)將會(huì)是系統(tǒng)產(chǎn)生很多的策略類(lèi)。

策略模式包含如下角色：
Context: 環(huán)境類(lèi)
Strategy: 抽象策略類(lèi)
ConcreteStrategy: 具體策略類(lèi)

16.狀態(tài)模式

在很多情況下我們對(duì)象的行為依賴(lài)于它的一個(gè)或者多個(gè)變化的屬性，這些可變的屬性我們稱(chēng)之為狀態(tài)，也就是說(shuō)行為依賴(lài)狀態(tài)，即當(dāng)該對(duì)象因?yàn)樵谕獠康幕?dòng)而導(dǎo)致他的狀態(tài)發(fā)生變化，從而它的行為也會(huì)做出相應(yīng)的變化。對(duì)于這種情況，我們是不能用行為來(lái)控制狀態(tài)的變化，而應(yīng)該站在狀態(tài)的角度來(lái)思考行為，即是什么狀態(tài)就要做出什么樣的行為。這個(gè)就是狀態(tài)模式。

所以狀態(tài)模式就是允許對(duì)象在內(nèi)部狀態(tài)發(fā)生改變時(shí)改變它的行為，對(duì)象看起來(lái)好像修改了它的類(lèi)。

在狀態(tài)模式中我們可以減少大塊的if…else語(yǔ)句，它是允許態(tài)轉(zhuǎn)換邏輯與狀態(tài)對(duì)象合成一體，但是減少if…else語(yǔ)句的代價(jià)就是會(huì)換來(lái)大量的類(lèi)，所以狀態(tài)模式勢(shì)必會(huì)增加系統(tǒng)中類(lèi)或者對(duì)象的個(gè)數(shù)。

同時(shí)狀態(tài)模式是將所有與某個(gè)狀態(tài)有關(guān)的行為放到一個(gè)類(lèi)中，并且可以方便地增加新的狀態(tài)，只需要改變對(duì)象狀態(tài)即可改變對(duì)象的行為。但是這樣就會(huì)導(dǎo)致系統(tǒng)的結(jié)構(gòu)和實(shí)現(xiàn)都會(huì)比較復(fù)雜，如果使用不當(dāng)就會(huì)導(dǎo)致程序的結(jié)構(gòu)和代碼混亂，不利于維護(hù)。

狀態(tài)模式包含如下角色：
Context: 環(huán)境類(lèi)
State: 抽象狀態(tài)類(lèi)
ConcreteState: 具體狀態(tài)類(lèi)

17.觀(guān)察者模式

何謂觀(guān)察者模式？觀(guān)察者模式定義了對(duì)象之間的一對(duì)多依賴(lài)關(guān)系，這樣一來(lái)，當(dāng)一個(gè)對(duì)象改變狀態(tài)時(shí)，它的所有依賴(lài)者都會(huì)收到通知并且自動(dòng)更新。

在這里，發(fā)生改變的對(duì)象稱(chēng)之為觀(guān)察目標(biāo)，而被通知的對(duì)象稱(chēng)之為觀(guān)察者。一個(gè)觀(guān)察目標(biāo)可以對(duì)應(yīng)多個(gè)觀(guān)察者，而且這些觀(guān)察者之間沒(méi)有相互聯(lián)系，所以么可以根據(jù)需要增加和刪除觀(guān)察者，使得系統(tǒng)更易于擴(kuò)展。所以觀(guān)察者提供了一種對(duì)象設(shè)計(jì)，讓主題和觀(guān)察者之間以松耦合的方式結(jié)合。

觀(guān)察者模式包含如下角色：
Subject: 目標(biāo)
ConcreteSubject: 具體目標(biāo)
Observer: 觀(guān)察者
ConcreteObserver: 具體觀(guān)察者

18.備忘錄模式

后悔藥人人都想要，但是事實(shí)卻是殘酷的，根本就沒(méi)有后悔藥可買(mǎi)，但是也不僅如此，在軟件的世界里就有后悔藥！備忘錄模式就是一種后悔藥，它給我們的軟件提供后悔藥的機(jī)制，通過(guò)它可以使系統(tǒng)恢復(fù)到某一特定的歷史狀態(tài)。

所謂備忘錄模式就是在不破壞封裝的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)，這樣可以在以后將對(duì)象恢復(fù)到原先保存的狀態(tài)。它實(shí)現(xiàn)了對(duì)信息的封裝，使得客戶(hù)不需要關(guān)心狀態(tài)保存的細(xì)節(jié)。保存就要消耗資源，所以備忘錄模式的缺點(diǎn)就在于消耗資源。如果類(lèi)的成員變量過(guò)多，勢(shì)必會(huì)占用比較大的資源，而且每一次保存都會(huì)消耗一定的內(nèi)存。

備忘錄模式包含如下角色：
Originator: 原發(fā)器
Memento: 備忘錄
Caretaker: 負(fù)責(zé)人

19.中介者模式

租房各位都有過(guò)的經(jīng)歷吧！在這個(gè)過(guò)程中中介結(jié)構(gòu)扮演著很重要的角色，它在這里起到一個(gè)中間者的作用，給我們和房主互相傳遞信息。在外面軟件的世界里同樣需要這樣一個(gè)中間者。在我們的系統(tǒng)中有時(shí)候會(huì)存在著對(duì)象與對(duì)象之間存在著很強(qiáng)、復(fù)雜的關(guān)聯(lián)關(guān)系，如果讓他們之間有直接的聯(lián)系的話(huà)，必定會(huì)導(dǎo)致整個(gè)系統(tǒng)變得非常復(fù)雜，而且可擴(kuò)展性很差！在前面我們就知道如果兩個(gè)類(lèi)之間沒(méi)有不必彼此通信，我們就不應(yīng)該讓他們有直接的關(guān)聯(lián)關(guān)系，如果實(shí)在是需要通信的話(huà)，我們可以通過(guò)第三者來(lái)轉(zhuǎn)發(fā)他們的請(qǐng)求。同樣，這里我們利用中介者來(lái)解決這個(gè)問(wèn)題。

所謂中介者模式就是用一個(gè)中介對(duì)象來(lái)封裝一系列的對(duì)象交互，中介者使各對(duì)象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。在中介者模式中，中介對(duì)象用來(lái)封裝對(duì)象之間的關(guān)系，各個(gè)對(duì)象可以不需要知道具體的信息通過(guò)中介者對(duì)象就可以實(shí)現(xiàn)相互通信。它減少了對(duì)象之間的互相關(guān)系，提供了系統(tǒng)可復(fù)用性，簡(jiǎn)化了系統(tǒng)的結(jié)構(gòu)。

在中介者模式中，各個(gè)對(duì)象不需要互相知道了解，他們只需要知道中介者對(duì)象即可，但是中介者對(duì)象就必須要知道所有的對(duì)象和他們之間的關(guān)聯(lián)關(guān)系，正是因?yàn)檫@樣就導(dǎo)致了中介者對(duì)象的結(jié)構(gòu)過(guò)于復(fù)雜，承擔(dān)了過(guò)多的職責(zé)，同時(shí)它也是整個(gè)系統(tǒng)的核心所在，它有問(wèn)題將會(huì)導(dǎo)致整個(gè)系統(tǒng)的問(wèn)題。所以如果在系統(tǒng)的設(shè)計(jì)過(guò)程中如果出現(xiàn)“多對(duì)多”的復(fù)雜關(guān)系群時(shí)，千萬(wàn)別急著使用中介者模式，而是要仔細(xì)思考是不是您設(shè)計(jì)的系統(tǒng)存在問(wèn)題。

Mediator: 抽象中介者
ConcreteMediator: 具體中介者
Colleague: 抽象同事類(lèi)
ConcreteColleague: 具體同事類(lèi)

20.迭代器模式

對(duì)于迭代在編程過(guò)程中我們經(jīng)常用到，能夠游走于聚合內(nèi)的每一個(gè)元素，同時(shí)還可以提供多種不同的遍歷方式，這就是迭代器模式的設(shè)計(jì)動(dòng)機(jī)。在我們實(shí)際的開(kāi)發(fā)過(guò)程中，我們可能會(huì)需要根據(jù)不同的需求以不同的方式來(lái)遍歷整個(gè)對(duì)象，但是我們又不希望在聚合對(duì)象的抽象接口中充斥著各種不同的遍歷操作，于是我們就希望有某個(gè)東西能夠以多種不同的方式來(lái)遍歷一個(gè)聚合對(duì)象，這時(shí)迭代器模式出現(xiàn)了。

何為迭代器模式？所謂迭代器模式就是提供一種方法順序訪(fǎng)問(wèn)一個(gè)聚合對(duì)象中的各個(gè)元素，而不是暴露其內(nèi)部的表示。迭代器模式是將迭代元素的責(zé)任交給迭代器，而不是聚合對(duì)象，我們甚至在不需要知道該聚合對(duì)象的內(nèi)部結(jié)構(gòu)就可以實(shí)現(xiàn)該聚合對(duì)象的迭代。

通過(guò)迭代器模式，使得聚合對(duì)象的結(jié)構(gòu)更加簡(jiǎn)單，它不需要關(guān)注它元素的遍歷，只需要專(zhuān)注它應(yīng)該專(zhuān)注的事情，這樣就更加符合單一職責(zé)原則了。

迭代器模式包含如下角色：
Iterator: 抽象迭代器
ConcreteIterator: 具體迭代器
Aggregate: 抽象聚合類(lèi)
ConcreteAggregate: 具體聚合類(lèi)

21.解釋器模式

所謂解釋器模式就是定義語(yǔ)言的文法，并且建立一個(gè)解釋器來(lái)解釋該語(yǔ)言中的句子。解釋器模式描述了如何構(gòu)成一個(gè)簡(jiǎn)單的語(yǔ)言解釋器，主要應(yīng)用在使用面向?qū)ο笳Z(yǔ)言開(kāi)發(fā)的編譯器中。它描述了如何為簡(jiǎn)單的語(yǔ)言定義一個(gè)文法，如何在該語(yǔ)言中表示一個(gè)句子，以及如何解釋這些句子。

解釋器模式包含如下角色：
AbstractExpression: 抽象表達(dá)式
TerminalExpression: 終結(jié)符表達(dá)式
NonterminalExpression: 非終結(jié)符表達(dá)式
Context: 環(huán)境類(lèi)
Client: 客戶(hù)類(lèi)

22.命令模式

有些時(shí)候我們想某個(gè)對(duì)象發(fā)送一個(gè)請(qǐng)求，但是我們并不知道該請(qǐng)求的具體接收者是誰(shuí)，具體的處理過(guò)程是如何的，們只知道在程序運(yùn)行中指定具體的請(qǐng)求接收者即可，對(duì)于這樣將請(qǐng)求封裝成對(duì)象的我們稱(chēng)之為命令模式。所以命令模式將請(qǐng)求封裝成對(duì)象，以便使用不同的請(qǐng)求、隊(duì)列或者日志來(lái)參數(shù)化其他對(duì)象。同時(shí)命令模式支持可撤銷(xiāo)的操作。

命令模式可以將請(qǐng)求的發(fā)送者和接收者之間實(shí)現(xiàn)完全的解耦，發(fā)送者和接收者之間沒(méi)有直接的聯(lián)系，發(fā)送者只需要知道如何發(fā)送請(qǐng)求命令即可，其余的可以一概不管，甚至命令是否成功都無(wú)需關(guān)心。同時(shí)我們可以非常方便的增加新的命令，但是可能就是因?yàn)榉奖愫蛯?duì)請(qǐng)求的封裝就會(huì)導(dǎo)致系統(tǒng)中會(huì)存在過(guò)多的具體命令類(lèi)。

命令模式包含如下角色：
Command: 抽象命令類(lèi)
ConcreteCommand: 具體命令類(lèi)
Invoker: 調(diào)用者
Receiver: 接收者
Client:客戶(hù)類(lèi)

23.責(zé)任鏈模式

職責(zé)鏈模式描述的請(qǐng)求如何沿著對(duì)象所組成的鏈來(lái)傳遞的。它將對(duì)象組成一條鏈，發(fā)送者將請(qǐng)求發(fā)給鏈的第一個(gè)接收者，并且沿著這條鏈傳遞，直到有一個(gè)對(duì)象來(lái)處理它或者直到最后也沒(méi)有對(duì)象處理而留在鏈末尾端。

避免請(qǐng)求發(fā)送者與接收者耦合在一起，讓多個(gè)對(duì)象都有可能接收請(qǐng)求，將這些對(duì)象連接成一條鏈，并且沿著這條鏈傳遞請(qǐng)求，直到有對(duì)象處理它為止，這就是職責(zé)鏈模式。在職責(zé)鏈模式中，使得每一個(gè)對(duì)象都有可能來(lái)處理請(qǐng)求，從而實(shí)現(xiàn)了請(qǐng)求的發(fā)送者和接收者之間的解耦。同時(shí)職責(zé)鏈模式簡(jiǎn)化了對(duì)象的結(jié)構(gòu)，它使得每個(gè)對(duì)象都只需要引用它的后繼者即可，而不必了解整條鏈，這樣既提高了系統(tǒng)的靈活性也使得增加新的請(qǐng)求處理類(lèi)也比較方便。但是在職責(zé)鏈中我們不能保證所有的請(qǐng)求都能夠被處理，而且不利于觀(guān)察運(yùn)行時(shí)特征。

職責(zé)鏈模式包含如下角色：
Handler: 抽象處理者
ConcreteHandler: 具體處理者
Client: 客戶(hù)類(lèi)

五、如何學(xué)習(xí)設(shè)計(jì)模式

說(shuō)明，《如何學(xué)習(xí)設(shè)計(jì)模式》轉(zhuǎn)摘自：http://blog.csdn.net/yqj2065/article/details/39103857

①學(xué)習(xí)技巧

學(xué)習(xí)設(shè)計(jì)模式時(shí)，有一些技巧能夠幫助你快速理解設(shè)計(jì)模式。

a) 使用較簡(jiǎn)單的面向?qū)ο蟮恼Z(yǔ)言如Java、C#。GoF的[設(shè)計(jì)模式]實(shí)質(zhì)上是面向?qū)ο蟮脑O(shè)計(jì)模式。[GoF·1.1]中提到“程序設(shè)計(jì)語(yǔ)言的選擇非常重要，它將影響人們理解問(wèn)題的出發(fā)點(diǎn)”。從學(xué)習(xí)設(shè)計(jì)模式的角度看，Java和C#較C++更容易一些。比如Java接口等，能夠更有效展現(xiàn)設(shè)計(jì)模式的意圖。

b) 使用工具BlueJ。BlueJ最大的好處，就是提供了簡(jiǎn)單的類(lèi)圖。正如我在簡(jiǎn)明設(shè)計(jì)模式Java中所做的，較少去專(zhuān)門(mén)畫(huà)類(lèi)圖，而是在BlueJ中截圖。在學(xué)生上機(jī)編寫(xiě)演示程序時(shí)，常常先看他的類(lèi)圖，以判斷他的程序是否正確，必要時(shí)再看源代碼。

c) 日常生活的隱喻。用一些實(shí)際生活中的例子來(lái)說(shuō)明某某模式，能夠讓你快速掌握某模式的目的和實(shí)現(xiàn)代碼的結(jié)構(gòu)。同時(shí)，你要認(rèn)識(shí)到，這種隱喻如同告訴你（2+3）2=22+2*2*3+32，你需要自己舉一反三，得出（a+b）2=a2+2ab+b2。在實(shí)際工作中的模式的具體應(yīng)用，則相當(dāng)于應(yīng)用代數(shù)公式。

d) 動(dòng)手實(shí)踐和懷疑精神?？达@淺的參考書(shū)或上網(wǎng)查閱資料時(shí)，要自己敲(復(fù)制也可以)代碼并運(yùn)行，要多修改別人的源代碼提出自己的觀(guān)點(diǎn)：為什么書(shū)中不這樣設(shè)計(jì)、為什么要那樣設(shè)計(jì)；如果增添一些方法、方法參數(shù)、或成員變量會(huì)如何？必須要自己親自動(dòng)手，最起碼要運(yùn)行。另外，要敢于向博主提問(wèn)、拍磚。你甚至可以質(zhì)疑GoF的某些章節(jié)的解說(shuō)和意圖，更何況一些博主呢。

②基礎(chǔ)知識(shí)

這些知識(shí)讓你知道，設(shè)計(jì)模式好在何處。

a)面向?qū)ο蠓妒?。也就是人們傳說(shuō)的思想。封裝、繼承和多態(tài)這些東西，在我看來(lái)比if、for等稍微高一點(diǎn)，也屬于語(yǔ)法問(wèn)題。面向?qū)ο缶幊桃莆盏?a rel="external nofollow" target="_blank" >三大原則是柏拉圖(Plato)原則、里氏(Liskov)替換原則和Parnas原則。這三個(gè)原則其實(shí)非常簡(jiǎn)單。任何原則，你覺(jué)得很難一見(jiàn)鐘情，很難快速認(rèn)同，那它就不會(huì)是好原則。

b)設(shè)計(jì)原則。許多人列舉了7大原則，如單一職責(zé)原則、開(kāi)閉原則、里氏代換原則、依賴(lài)倒轉(zhuǎn)原則、接口隔離原則、合成復(fù)用原則、迪米特法則。LSP，我將它提升為面向?qū)ο蠓妒降?大基石之一；單一職責(zé)和接口隔離，主要作為面向?qū)ο蠓治?OOA時(shí)職責(zé)劃分所遵循的原則，此時(shí)你可以不太在意。依賴(lài)倒轉(zhuǎn)原則，我把它作為垃圾扔掉，因?yàn)殚_(kāi)閉原則或者直接地說(shuō)“依賴(lài)于抽象類(lèi)型原則”已經(jīng)包含了依賴(lài)倒轉(zhuǎn)原則的精華，而依賴(lài)倒轉(zhuǎn)原則的糟粕由IoC繼承。當(dāng)然，回調(diào)，我很強(qiáng)調(diào)。所以，你要掌握的有抽象依賴(lài)原則(OCP)、單向依賴(lài)原則(含對(duì)回調(diào)的學(xué)習(xí))和最低依賴(lài)原則(合成復(fù)用原則、迪米特法則)。

c) UML的初步了解。這是學(xué)習(xí)設(shè)計(jì)模式的工具。在早期，你甚至可以?xún)H了解BlueJ的相關(guān)圖示，也就10分鐘的事情。

③境界

《五燈會(huì)元》卷十七中，有一則唐朝禪師青原惟信禪師的語(yǔ)錄:“老僧三十年前未參禪時(shí)，見(jiàn)山是山，見(jiàn)水是水。及至后來(lái)親見(jiàn)知識(shí)，有個(gè)入處，見(jiàn)山不是山，見(jiàn)水不是水。而今得個(gè)休歇處，依前見(jiàn)山只是山，見(jiàn)水只是水?！?/p>

a) 仔細(xì)研究GoF的[設(shè)計(jì)模式]，逐個(gè)學(xué)習(xí)其意圖和結(jié)構(gòu)，是一個(gè)抱著字典學(xué)習(xí)英語(yǔ)的方式。見(jiàn)山是山，見(jiàn)水是水，導(dǎo)致你可能在實(shí)際工作中生搬硬套、東施效顰。

b) 建議從簡(jiǎn)單的場(chǎng)景出發(fā)，自己發(fā)現(xiàn)或設(shè)計(jì)出某種模式。你從中體會(huì)該模式是如何解決問(wèn)題的，這樣，該模式成為你自己的東西，你才不會(huì)出現(xiàn)知易行難的問(wèn)題。所有的設(shè)計(jì)模式不過(guò)是基本原則和理念在特定場(chǎng)合的應(yīng)用。你可能不知道某個(gè)設(shè)計(jì)模式的名字，但是你知道它一切的優(yōu)缺點(diǎn)和變體以及應(yīng)用場(chǎng)合。見(jiàn)山不是山，見(jiàn)水不是水。

c) 你對(duì)基本原則和理念融會(huì)貫通，你可以惋惜：“我找到一種模式，原來(lái)在[設(shè)計(jì)模式](其實(shí)是某個(gè)特殊的書(shū)、文章提到的模式)中早就有了這種模式”。這時(shí)，模式不模式又如何呢？反模式又怎樣。看見(jiàn)一個(gè)模式，你會(huì)說(shuō)：“嗯，這是一種有用的模式”。見(jiàn)山只是山，見(jiàn)水只是水。

以上一點(diǎn)淺見(jiàn)。

注：【】中的內(nèi)容是我加的。

1轉(zhuǎn)錄【IT168知識(shí)庫(kù)】

      發(fā)現(xiàn)很多初學(xué)設(shè)計(jì)模式的人都有一些特點(diǎn)就是學(xué)習(xí)了某個(gè)設(shè)計(jì)模式之后，貌似理解了，但是卻不知道怎么去使用這些所謂的精華經(jīng)驗(yàn)，苦于不知如何下手。我最初學(xué)習(xí)設(shè)計(jì)模式的時(shí)候也有類(lèi)似的經(jīng)驗(yàn)，我將我的經(jīng)驗(yàn)分享出來(lái)，希望能對(duì)初學(xué)者有幫助。 

我對(duì)設(shè)計(jì)模式產(chǎn)生興趣是在大概一年以前，最初看書(shū)的時(shí)候好像是看懂了，大概知道他在說(shuō)什么?？戳藥讉€(gè)模式之后就開(kāi)始尋找時(shí)機(jī)來(lái)套用套用這些模式。結(jié)果是除了Singleton模式以外的其他模式都沒(méi)有找到應(yīng)用的場(chǎng)所。然后我就沒(méi)開(kāi)始看下去了，我知道再看也沒(méi)用，但是我并沒(méi)有放棄對(duì)設(shè)計(jì)模式的關(guān)注。

不久我就在MSDN的Webcast上看到李建忠的 C#面向?qū)ο笤O(shè)計(jì)模式縱橫談講座，很不錯(cuò)的系列講座，讓我對(duì)設(shè)計(jì)模式有了新的理解。我意識(shí)到學(xué)習(xí)設(shè)計(jì)模式，確切的講是學(xué)習(xí)面向?qū)ο蟮脑O(shè)計(jì)模式，應(yīng)該從學(xué)習(xí)面向?qū)ο箝_(kāi)始?！久嫦?qū)ο蟮脑砣缤私庀孪笃宓囊?guī)則，而設(shè)計(jì)模式相當(dāng)于殘局，不知道規(guī)則看什么殘局】由于之前一年都在做asp.net開(kāi)發(fā)，雖然都是在寫(xiě)類(lèi)、學(xué)著duwamish搞分層架構(gòu)、搞類(lèi)型化DataSet、也弄過(guò)自定義實(shí)體類(lèi)，但好像一年下來(lái)還沒(méi)怎么用過(guò)接口，什么多態(tài)也是極少用。事實(shí)上對(duì)面向?qū)ο蟮木幊趟枷氲恼J(rèn)識(shí)還是很模糊的。

重新認(rèn)識(shí)OO：面向?qū)ο缶幊淌且环N思想，以面向?qū)ο蟮乃季S來(lái)思考軟件設(shè)計(jì)結(jié)構(gòu)，從而強(qiáng)化面向?qū)ο蟮木幊谭妒健Ｃ嫦驅(qū)ο蟮奶攸c(diǎn)是封裝，繼承，多態(tài)【這些也算？】。所以從那是開(kāi)始，當(dāng)我設(shè)計(jì)一個(gè)類(lèi)的時(shí)候，不斷的提示自己以下三點(diǎn)：
第一：別把自己的數(shù)據(jù)公開(kāi)，除非你要向別人提供數(shù)據(jù)，使用盡量低的訪(fǎng)問(wèn)權(quán)限。
第二：以一個(gè)外部的視角來(lái)看類(lèi)，緊記不要要求別人要在知道你是怎么實(shí)現(xiàn)一個(gè)方法之后才能使用我的類(lèi)。
第三：分清類(lèi)的職責(zé)，該這個(gè)類(lèi)做的事情就要在這個(gè)類(lèi)中實(shí)現(xiàn)，不該我的類(lèi)做的事情就讓別的類(lèi)去實(shí)現(xiàn)。
在這三點(diǎn)的指導(dǎo)下來(lái)寫(xiě)類(lèi)，寫(xiě)程序開(kāi)始像在做“設(shè)計(jì)”了^_^。
一段時(shí)間后對(duì)設(shè)計(jì)模式就慢慢有感覺(jué)了，并能夠找到一些設(shè)計(jì)模式的應(yīng)用場(chǎng)景了。并常套用套用那些模式，逐漸的加深對(duì)模式的理解，并把它變成自己的東西，能夠在其他的地方靈活的用起來(lái)。

2.轉(zhuǎn)錄 《易學(xué)設(shè)計(jì)模式·1.4 如何學(xué)習(xí)設(shè)計(jì)模式》郭志學(xué) 人民郵電出版社

如何學(xué)習(xí)設(shè)計(jì)模式
在了解了設(shè)計(jì)模式的歷史和分類(lèi)后，應(yīng)該如何學(xué)習(xí)設(shè)計(jì)模式呢？在學(xué)習(xí)設(shè)計(jì)模式之前，讀者一定要樹(shù)立一種意識(shí)，那就是：設(shè)計(jì)模式并不只是一種方法和技術(shù)，它更是一種思想、一個(gè)方法論。它和具體的語(yǔ)言沒(méi)有關(guān)系，學(xué)習(xí)設(shè)計(jì)模式最主要的目的就是要建立面向?qū)ο蟮乃枷?，盡可能地面向接口編程、低耦合、高內(nèi)聚，使你設(shè)計(jì)的程序盡可能地復(fù)用?！舅剖嵌?。學(xué)習(xí)設(shè)計(jì)模式能夠更好理解面向?qū)ο蟮乃枷?，設(shè)計(jì)模式是一些設(shè)計(jì)的技巧和竅門(mén)，不要上升到思想、方法論好不好】
有些軟件開(kāi)發(fā)人員，在程序設(shè)計(jì)時(shí)，總想著往某個(gè)設(shè)計(jì)模式上套，其實(shí)這樣是不對(duì)的，并沒(méi)有真正掌握設(shè)計(jì)模式的思想。其實(shí)很多時(shí)候讀者用了某種設(shè)計(jì)模式，只是自己不知道這個(gè)模式叫什么名字而已。因此，在程序設(shè)計(jì)時(shí)，要根據(jù)自己的理解，使用合適的設(shè)計(jì)模式。
而有另外一些軟件開(kāi)發(fā)人員，在程序設(shè)計(jì)時(shí)，動(dòng)不動(dòng)就給類(lèi)起個(gè)類(lèi)似模式的名字，比如叫某某Facade、某某Factory等，其實(shí)類(lèi)里面的內(nèi)容和設(shè)計(jì)模式根本沒(méi)有一點(diǎn)關(guān)系，只是用來(lái)標(biāo)榜自己懂設(shè)計(jì)模式而已。
因此，學(xué)習(xí)設(shè)計(jì)模式，首先要了解有哪些方面的設(shè)計(jì)模式可以供開(kāi)發(fā)人員使用，然后再分別研究每個(gè)設(shè)計(jì)模式的原理，使用時(shí)機(jī)和方法，也就是說(shuō)要在什么情況下才使用某個(gè)設(shè)計(jì)模式，在了解某個(gè)設(shè)計(jì)模式的使用時(shí)機(jī)時(shí)，還要了解此時(shí)如果不使用這個(gè)設(shè)計(jì)模式，會(huì)造成什么樣的后果。當(dāng)對(duì)每個(gè)模式的原理和使用方法都了解了以后，更重要的是，學(xué)習(xí)面向?qū)ο蟮乃枷敕绞?，在掌握面向?qū)ο蟮乃枷敕绞胶螅倩剡^(guò)頭來(lái)看設(shè)計(jì)模式，就會(huì)有更深刻的理解，最后，學(xué)習(xí)設(shè)計(jì)模式，一定要勤學(xué)多練?！揪妥詈笠痪浜苜澩?/p>

六、個(gè)人感悟

學(xué)習(xí)設(shè)計(jì)模式確實(shí)有幾種境界：

第一種是學(xué)習(xí)了一兩個(gè)設(shè)計(jì)模式，就一直想用到自己的代碼中去；

第二種是學(xué)完全部設(shè)計(jì)模式，覺(jué)得很多模式都很相似，分不清楚它們之間有什么區(qū)別；

第三種是靈活運(yùn)用設(shè)計(jì)模式，就算不用具體哪種模式也可以設(shè)計(jì)也高質(zhì)量的代碼，無(wú)劍勝有劍。

最后附上總結(jié)圖：

感謝：博客園的chenssy Bobby0322 等博主，看了你們寫(xiě)的博客后受益匪淺，謝謝。

接下來(lái)，從10月份開(kāi)始學(xué)習(xí)JDK & JAVA 知識(shí)提高。

到此這篇關(guān)于Java設(shè)計(jì)模式之23種設(shè)計(jì)模式詳解的文章就介紹到這了,更多相關(guān)Java 23種 設(shè)計(jì)模式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論