系列文章目錄

文章目錄

• 系列文章目錄
• 前言
• 一、策略模式
• • 1.業(yè)務(wù)場(chǎng)景：
  • 2.定義：
  • 3.項(xiàng)目應(yīng)用：
• 二、觀察者模式
• • 1.業(yè)務(wù)場(chǎng)景
  • 2.定義
• 三、裝飾者模式
• • 1.業(yè)務(wù)場(chǎng)景
  • 2.定義：
• 四、工廠模式
• • 1.業(yè)務(wù)場(chǎng)景
  • 2.定義：
  • 3.定義：
• 五、單例模式
• • 1.業(yè)務(wù)場(chǎng)景
  • 2.定義
  • 3.應(yīng)用場(chǎng)景：
• 六、命令模式
• • 1.業(yè)務(wù)場(chǎng)景
  • 2.定義
  • 3.應(yīng)用場(chǎng)景：
• 七、適配器模式
• • 1.業(yè)務(wù)場(chǎng)景
  • 2.定義
  • 3.應(yīng)用場(chǎng)景
• 八、外觀模式
• • 1.業(yè)務(wù)場(chǎng)景
  • 2.定義
• 九、模板模式
• • 1.業(yè)務(wù)場(chǎng)景
  • 2.定義
• 總結(jié)

---

前言

`
設(shè)計(jì)模式有兩種分類方法，即根據(jù)模式的目的來分和根據(jù)模式的作用的范圍來分。

根據(jù)目的來分
根據(jù)模式是用來完成什么工作來劃分，這種方式可分為創(chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式 3 種。
1.創(chuàng)建型模式：用于描述“怎樣創(chuàng)建對(duì)象”，它的主要特點(diǎn)是“將對(duì)象的創(chuàng)建與使用分離”。GoF 中提供了單例、原型、工廠方法、抽象工廠、建造者等 5 種創(chuàng)建型模式。
2結(jié)構(gòu)型模式：用于描述如何將類或?qū)ο蟀茨撤N布局組成更大的結(jié)構(gòu)，GoF 中提供了代理、適配器、橋接、裝飾、外觀、享元、組合等 7 種結(jié)構(gòu)型模式。
3.行為型模式：用于描述類或?qū)ο笾g怎樣相互協(xié)作共同完成單個(gè)對(duì)象都無法單獨(dú)完成的任務(wù)，以及怎樣分配職責(zé)。GoF 中提供了模板方法、策略、命令、職責(zé)鏈、狀態(tài)、觀察者、中介者、迭代器、訪問者、備忘錄、解釋器等 11 種行為型模式。

根據(jù)作用范圍來分
根據(jù)模式是主要用于類上還是主要用于對(duì)象上來分，這種方式可分為類模式和對(duì)象模式兩種。
1.類模式：用于處理類與子類之間的關(guān)系，這些關(guān)系通過繼承來建立，是靜態(tài)的，在編譯時(shí)刻便確定下來了。GoF中的工廠方法、（類）適配器、模板方法、解釋器屬于該模式。
2.對(duì)象模式：用于處理對(duì)象之間的關(guān)系，這些關(guān)系可以通過組合或聚合來實(shí)現(xiàn)，在運(yùn)行時(shí)刻是可以變化的，更具動(dòng)態(tài)性。GoF 中除了以上 4 種，其他的都是對(duì)象模式。

---

提示：以下是本篇文章正文內(nèi)容，下面案例可供參考

一、策略模式

1.業(yè)務(wù)場(chǎng)景：

我們想讓鴨子可以飛，可以在抽象類Duck中添加fly()方法

業(yè)務(wù)發(fā)展，現(xiàn)在我們新增一種鴨子叫木頭鴨，既不會(huì)飛，也不會(huì)叫，我們可以讓木頭鴨繼承Duck ,覆蓋fly()和quack()，實(shí)現(xiàn)不會(huì)飛也不會(huì)叫。
但是通過繼承來提供Duck的行為，有以下缺點(diǎn)：
1.代碼在多個(gè)子類中重復(fù)
2.運(yùn)行時(shí)的行為不容易改變
3.很難知道鴨子的所有行為
4.改變會(huì)牽一發(fā)而動(dòng)全身，造成其它鴨子不想要的改變

利用接口如何？

需要飛行或者會(huì)叫的鴨子分別實(shí)現(xiàn)Flyable和Quackable這兩個(gè)接口，雖然解決了新增的鴨子需要什么行為就實(shí)現(xiàn)什么接口的問題，但是還是無法解決代碼復(fù)用的問題，因?yàn)槿绻蠖鄶?shù)的鴨子會(huì)飛的行為一致，在每一個(gè)鴨子類中都需要實(shí)現(xiàn)同樣的方法。

設(shè)計(jì)原則

找出應(yīng)用可能需要變化之處，把它們獨(dú)立出來，不要和那些不需要變化的代碼放在一起

我們知道Duck類中fly()和quack()會(huì)隨著鴨子的不同而改變，為了要把這兩個(gè)行為從Duck中分開，我們將把它們從Duck類中取出來，建立一組新類來代表每個(gè)行為。

這樣的設(shè)計(jì)，可以讓飛行和呱呱叫的動(dòng)作被其他的對(duì)象復(fù)用，因?yàn)檫@些行為已經(jīng)與鴨子類無關(guān)了，我們也可以新增一些行為，不會(huì)影響到既有的行為類，也不會(huì)影響到使用到行為類的鴨子了。
同時(shí)也引出新的設(shè)計(jì)原則，這樣在運(yùn)行時(shí)才指定具體實(shí)現(xiàn)的類。

設(shè)計(jì)原則
2. 針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)編程

關(guān)鍵在于，鴨子將飛行和呱呱叫的行為委托（delegate）給別人處理，而不是定義在鴨子類中的方法。

同時(shí)，還支持動(dòng)態(tài)設(shè)定行為

完整類圖：

設(shè)計(jì)原則
3. 多用組合，少用繼承

2.定義：

定義算法族，分別封裝起來，讓他們可以相互替換，讓算法變化對(duì)客戶端透明。

3.項(xiàng)目應(yīng)用：

多平臺(tái)入駐項(xiàng)目有十幾個(gè)平臺(tái)，都需要對(duì)入?yún)⑦M(jìn)行校驗(yàn)，校驗(yàn)邏輯不一樣，但其他環(huán)節(jié)一致，這時(shí)候抽出校驗(yàn)算法的接口，提供一組實(shí)現(xiàn)該接口的策略類。

二、觀察者模式

1.業(yè)務(wù)場(chǎng)景

氣象站通過感應(yīng)裝置獲取實(shí)時(shí)天氣數(shù)據(jù)，然后更新到看板上

weatherData對(duì)象獲取氣象站更新的數(shù)據(jù)，并更新三個(gè)布告板：目前狀況，氣象統(tǒng)計(jì)，天氣預(yù)報(bào)，業(yè)務(wù)必須支持?jǐn)U展新的布告板。


缺點(diǎn)：
1.針對(duì)具體實(shí)現(xiàn)編程，而非針對(duì)接口。
2.對(duì)于每個(gè)新的布告板，得修改代碼。
3.無法在運(yùn)行時(shí)動(dòng)態(tài)的增加或刪除布告板。
4.沒有封裝改變的部分。

2.定義

定義對(duì)象之間的一對(duì)多依賴，當(dāng)一端對(duì)象發(fā)生變換，它的所有依賴者都會(huì)收到通知并自動(dòng)更新。

發(fā)布者 + 訂閱者 = 觀察者模式

類圖：

當(dāng)兩個(gè)對(duì)象之間松耦合，他們依然可以交互，但是不太清楚彼此的細(xì)節(jié)，觀察者模式提供了這樣一種對(duì)象之間松耦合的設(shè)計(jì)。
因?yàn)橹黝}只知道觀察者實(shí)現(xiàn)了observe接口，并不知道具體的實(shí)現(xiàn)類是什么，只依賴一個(gè)實(shí)現(xiàn)了該接口的觀察者列表，無論是往改列表中新增或刪除觀察者，主題都不受影響。

設(shè)計(jì)原則
4. 為了交互對(duì)象之間的松耦合設(shè)計(jì)而努力

具體實(shí)現(xiàn)代碼：


除了像上面主題的數(shù)據(jù)發(fā)生變化就像觀察者推送數(shù)據(jù)外，還可以讓觀察者主動(dòng)拉取數(shù)據(jù)，
而java內(nèi)置的觀察者模式兩張方式都支持。

如何把對(duì)象變成觀察者：
實(shí)現(xiàn)觀察者接口，然后調(diào)用任何Observable對(duì)象的addObserver()方法，不想當(dāng)觀察者時(shí)，調(diào)用deleteObserver()方法就行了
可觀察者要如何送出通知：
1.先調(diào)用setChanged()方法，標(biāo)記狀態(tài)已經(jīng)改變的事實(shí)。
2.然后調(diào)用兩種notifyObservers()或notifyObservers(Objecr arg)
觀察者如何接收通知
觀察者實(shí)現(xiàn)了更新的方法：

如果你想推數(shù)據(jù)給觀察者，你可以把數(shù)據(jù)當(dāng)做數(shù)據(jù)對(duì)象傳送給notifyObservers(Objecr arg)方法，否則，觀察者就必須從可觀察者對(duì)象中拉數(shù)據(jù)，如何拉數(shù)據(jù)？


java內(nèi)置的觀察者模式的局限性：
1.Observable 是一個(gè)類，因?yàn)閖ava不支持多重繼承，如果一個(gè)類還想繼承其它類，這限制了Observable的復(fù)用能力。
2.Observabel將關(guān)鍵的setChanged()方法保護(hù)起來了(被定義為protected),這導(dǎo)致Observabel無法被組合到其它類中，違背了設(shè)計(jì)原則：多用組合，少用繼承。
綜上，我們也可根據(jù)業(yè)務(wù)自己實(shí)現(xiàn)一整套觀察者模式。

三、裝飾者模式

1.業(yè)務(wù)場(chǎng)景

計(jì)算出每種咖啡的價(jià)格，購買咖啡時(shí)，也可以向其加入調(diào)料，計(jì)算總共的價(jià)格

一種錯(cuò)誤的實(shí)現(xiàn)方式：

通過繼承，得到每種調(diào)料和咖啡的價(jià)格匯總，但是會(huì)造成類數(shù)量龐大，維護(hù)困難，調(diào)料價(jià)格和新增調(diào)料時(shí)，都需要修改代碼。
其它的嘗試：

這樣雖然減少了大量的調(diào)料類，但是還存在一下缺點(diǎn)：
1.調(diào)料價(jià)錢變化，需要修改代碼
2.增加新的調(diào)料，需要加的新的方法，并改變超類中的cost()方法
3.新的調(diào)料，子類不適合，子類也需要繼承那些不適合的方法
4.當(dāng)顧客需要雙份調(diào)料時(shí)，現(xiàn)有代碼不支持

設(shè)計(jì)原則
5. 類應(yīng)該對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。

用裝飾者構(gòu)造飲料訂單
1.以DorkRoast對(duì)象開始

2.顧客想要摩卡(Mocha)，所以建立一個(gè)摩卡對(duì)象，并用它將DorkRoast對(duì)象包(Wrap)起來

3.顧客也想要奶泡(Whip)，所以需要建立一個(gè)Whip裝飾者，并用它將mocha對(duì)象包起來。

4.現(xiàn)在給顧客算錢，通過調(diào)用最外圍的裝飾者(Whip)的cost()就可以辦得到，Whip的cost()會(huì)先委托它裝飾的對(duì)象(也就是Mocha)計(jì)算出價(jià)錢，在加上奶泡的價(jià)錢。

1.裝飾者和被裝飾者擁有相同的類型
2.你可以用一個(gè)或多個(gè)裝飾者包裝對(duì)象
3.在任何需要被裝飾過的場(chǎng)合，都可以使用裝飾者對(duì)象代替它
4.裝飾者可以在被裝飾者的前后，加上自己的行為
5.對(duì)象可以在任何時(shí)候被裝飾，所以可以在運(yùn)行時(shí)動(dòng)態(tài)的使用裝飾者來裝飾對(duì)象

2.定義：

動(dòng)態(tài)的將責(zé)任附加到對(duì)象上，若要擴(kuò)展功能，裝飾者提供了比繼承更有彈性的替代方案。

類圖：

代碼實(shí)現(xiàn)：





裝飾者通過繼承達(dá)到和被裝飾者類型匹配，再通過組合獲得其行為，使用組合，可以把調(diào)料和飲料互相混合。
應(yīng)用場(chǎng)景：
Java I/O

編寫一個(gè)裝飾者，把輸入流內(nèi)所有的大寫字符都轉(zhuǎn)成小寫：


裝飾者模式的局限性：
1.會(huì)引入很多小類，會(huì)讓程序變得復(fù)雜，不利于理解整體設(shè)計(jì)
2.插入被裝飾對(duì)象容易插錯(cuò)，需要小心謹(jǐn)慎

四、工廠模式

1.業(yè)務(wù)場(chǎng)景

根據(jù)不同的輸入制作不同類型的披薩

業(yè)務(wù)發(fā)展，現(xiàn)在我們需要增加一些流行的披薩，而一些賣的不好的披薩要去除

如果實(shí)例化披薩出現(xiàn)問題，將使得整個(gè)制作披薩過程失敗，且對(duì)修改 沒有關(guān)閉，應(yīng)該將變化的部分抽出來封裝在一個(gè)新對(duì)象中，這個(gè)對(duì)象負(fù)責(zé)創(chuàng)建披薩，我們稱這個(gè)新對(duì)象為工廠

創(chuàng)建一個(gè)簡(jiǎn)單工廠

簡(jiǎn)單工廠類圖：

業(yè)務(wù)發(fā)展，現(xiàn)在需要在其它地方開加盟店，但是不同區(qū)域的口味不一樣，可以創(chuàng)建各個(gè)區(qū)域的簡(jiǎn)單工廠去制作披薩，還可以多一些質(zhì)量控制，加入自己的流程。

允許子類做決定，制作適合自己區(qū)域口味的披薩

之前是由一個(gè)對(duì)象負(fù)責(zé)所有具體類的實(shí)例化，現(xiàn)在變成由一群子類來實(shí)例化，

披薩類：

2.定義：

工廠方法模式定義了一個(gè)創(chuàng)建對(duì)象的接口，但由子類決定要實(shí)例化的類是哪一個(gè)，工廠方法讓類把實(shí)例化推遲到子類。

類圖：

工廠方法模式通過讓子類來決定該創(chuàng)建的對(duì)象是什么

設(shè)計(jì)原則
6. 要依賴抽象，不要依賴具體類

這個(gè)原則說明了：不能讓高層組件依賴底層組件，而且，不管高層組件還是底層組件，兩者都應(yīng)該依賴于抽象。
反面案例：

正確方式：

幾個(gè)方針能幫你避免在OO設(shè)計(jì)中違反此原則
1.變量不可以持有具體類的引用
2.盡量不要讓類派生自具體類
3.盡量不要覆蓋基類中已實(shí)現(xiàn)的方法

業(yè)務(wù)發(fā)展，不同區(qū)域的披薩需要使用不同的原料來制作，以迎合當(dāng)?shù)厝说目谖丁?br />

3.定義：

抽象工廠模式提供了一個(gè)接口，用于創(chuàng)建相關(guān)或依賴對(duì)象的家族，而不需要明確指定具體類。

類圖：



工廠方法和抽象工廠的區(qū)別？
工廠方法使用繼承：把對(duì)象的創(chuàng)建委托給子類，子類實(shí)現(xiàn)工廠方法來創(chuàng)建對(duì)象，允許類將實(shí)例化延遲到子類進(jìn)行。
抽象工廠使用對(duì)象組合：對(duì)象的創(chuàng)建被實(shí)現(xiàn)在工廠接口所暴露出來的方法中，創(chuàng)建相關(guān)的對(duì)象家族，而不需要依賴它們的具體類。

五、單例模式

1.業(yè)務(wù)場(chǎng)景

有一些對(duì)象其實(shí)我們只需要一個(gè)，比方說：線程池，緩存，注冊(cè)表，日志對(duì)象等

2.定義

單例模式確保一個(gè)類只有一個(gè)實(shí)例，并提供一個(gè)全局訪問點(diǎn)。

單例模式注意點(diǎn)：
1.私有化構(gòu)造函數(shù)
2.提供一個(gè)全局訪問點(diǎn)

實(shí)現(xiàn)方式：

餓漢模式

在這里插入代碼片 public class Singleton { private static Singleton instance = new Singleton(); private Singleton (){}public static Singleton getInstance() { return instance; } }

懶漢模式

public class Singleton { private static Singleton instance; private Singleton (){}public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } }

雙重檢查模式 （DCL）

public class Singleton { private volatile static Singleton singleton; private Singleton (){} public static Singleton getInstance() { if (instance== null) { synchronized (Singleton.class) { if (instance== null) { instance= new Singleton(); } } } return singleton; } }

靜態(tài)內(nèi)部類模式

public class Singleton { private Singleton(){}public static Singleton getInstance(){ return SingletonHolder.sInstance; } private static class SingletonHolder { private static final Singleton sInstance = new Singleton(); } }

枚舉單例

public enum Singleton { INSTANCE; public void doSomeThing() { } }

3.應(yīng)用場(chǎng)景：

servlet單例、struts2多例、springmvc單例，數(shù)據(jù)庫連接池，線程池，?站的計(jì)數(shù)器，日志應(yīng)用，web應(yīng)用配置文件等
（1）資源共享的情況下，避免由于資源操作時(shí)導(dǎo)致的性能問題或損耗等。如上述中的日志文件，應(yīng)用配置。
（2）控制資源的情況下，方便資源之間的互相通信。如線程池等。

六、命令模式

1.業(yè)務(wù)場(chǎng)景

設(shè)計(jì)一個(gè)家電自動(dòng)化遙控器的API，這個(gè)遙控器有7個(gè)插槽，分別都有對(duì)應(yīng)的開關(guān)，還具體一個(gè)整體的撤銷按鈕。
希望能夠創(chuàng)建一組控制遙控器的API，讓每個(gè)插槽都能控制一個(gè)或一組裝置，同時(shí)也能夠控制未來可能出現(xiàn)的裝置。


遙控器應(yīng)該知道如何解讀按鈕被按下的動(dòng)作，然后發(fā)出請(qǐng)求，但是不需要知道這些家電自動(dòng)化的細(xì)節(jié)。
命令模式將動(dòng)作的請(qǐng)求者和執(zhí)行者解耦，遙控器是請(qǐng)求者，執(zhí)行者是廠商類之一的實(shí)例。
命令接口：

2.定義

命令模式將請(qǐng)求封裝成對(duì)象，以便使用不同的請(qǐng)求、隊(duì)列或者日志來參數(shù)化其他對(duì)象。命令模式也支持撤銷的操作




擴(kuò)展，遙控器加上撤銷命令，和宏命令(一組命令的行為)應(yīng)該怎么設(shè)計(jì)？

3.應(yīng)用場(chǎng)景：

JDK源碼解析 Runable是一個(gè)典型命令模式，Runnable擔(dān)當(dāng)命令的角色，Thread充當(dāng)?shù)氖钦{(diào)用者，start方法就是其執(zhí)行方法

//命令接口(抽象命令角色) public interface Runnable {public abstract void run(); } ? //調(diào)用者 public class Thread implements Runnable {private Runnable target;public synchronized void start() {if (threadStatus != 0)throw new IllegalThreadStateException(); ?group.add(this); ?boolean started = false;try {start0();started = true;} finally {try {if (!started) {group.threadStartFailed(this);}} catch (Throwable ignore) {}}}private native void start0(); }

會(huì)調(diào)用一個(gè)native方法start0(),調(diào)用系統(tǒng)方法，開啟一個(gè)線程。而接收者是對(duì)程序員開放的，可以自己定義接收者。

/*** jdk Runnable 命令模式* TurnOffThread ： 屬于具體*/ public class TurnOffThread implements Runnable{private Receiver receiver;public TurnOffThread(Receiver receiver) {this.receiver = receiver;}public void run() {receiver.turnOFF();} *** 測(cè)試類*/ public class Demo {public static void main(String[] args) {Receiver receiver = new Receiver();TurnOffThread turnOffThread = new TurnOffThread(receiver);Thread thread = new Thread(turnOffThread);thread.start();} }

七、適配器模式

1.業(yè)務(wù)場(chǎng)景

優(yōu)點(diǎn)，不需要修改兩邊的代碼，讓兩邊的接口解耦了。
案例：
定義鴨子

一個(gè)綠頭鴨實(shí)現(xiàn)類

定義火雞

火雞實(shí)現(xiàn)類

現(xiàn)在沒有鴨子，需要用火雞來假冒鴨子

2.定義

適配器模式將一個(gè)類的接口，轉(zhuǎn)換成客戶期望的另一個(gè)接口。適配器讓原本接口不兼容的類可以合作無間。

適配器有兩種，一種是面向?qū)ο筮m配器，一種是類適配器
區(qū)別：對(duì)象適配器使用組合，類適配器使用繼承
使用組合，可以擴(kuò)展使用不同類型的被裝飾者
使用繼承，可以復(fù)用被裝飾者的方法，少些一些代碼

JAVA中的適配器

3.應(yīng)用場(chǎng)景

1.封裝有缺陷的接口，統(tǒng)一多個(gè)類的接口，兼容老版本接口
2.JDBC定義了一套操作數(shù)據(jù)庫的抽象接口，每個(gè)廠商提供了各自的驅(qū)動(dòng)實(shí)現(xiàn)這套接口。

八、外觀模式

1.業(yè)務(wù)場(chǎng)景

在觀看家庭影院是，需要做一些列的操作：

缺點(diǎn)：
1.看完電影需要關(guān)掉怎么辦，全部反向操作一次嗎
2.如果聽歌也會(huì)這么麻煩嗎
3.升級(jí)系統(tǒng)，還需要重新實(shí)現(xiàn)一套不同的過程

外觀不僅實(shí)現(xiàn)了接口，也將客戶從子系統(tǒng)解耦
外觀模式

2.定義

外觀模式，也叫門面模式，提供了一個(gè)統(tǒng)一的接口，用來訪問子系統(tǒng)中的一群接口，外觀定義了一個(gè)高層接口，讓子系統(tǒng)更容易使用。

設(shè)計(jì)原則
7. 最少知識(shí)原則：只和你的密友交談

最少知識(shí)原則，也叫 得墨彌耳定律
先來看看這段代碼耦合了多少類

在對(duì)象的方法內(nèi)，我們只應(yīng)該調(diào)用以下范圍的方法
1.該對(duì)象本身
2.方法入?yún)魅氲膮?shù)
3.此方法創(chuàng)建或?qū)嵗膶?duì)象
4.對(duì)象的任何組件

適配器將一個(gè)對(duì)象包裝起來已改變其接口，
裝飾者將一個(gè)對(duì)象包裝起來以增加新的行為和責(zé)任，
而外觀將一群對(duì)象包裝起來簡(jiǎn)化其接口

九、模板模式

1.業(yè)務(wù)場(chǎng)景

星巴克制作咖啡和茶的方法實(shí)現(xiàn)

子類代碼重復(fù)，算法改變，需要修改子類代碼

2.定義

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


可以預(yù)埋鉤子方法，由子類選擇是否覆蓋

設(shè)計(jì)原則
8.別調(diào)用我們，我們會(huì)調(diào)用你

模板方法與策略區(qū)別：策略模式和模板方法模式第一封裝算法，一個(gè)用組合，一個(gè)用繼承

總結(jié)

1.策略模式(Strategy)
定義算法，將他們分別封裝起來，讓他們可以相互替換，讓算法變化對(duì)客戶端透明。
2.觀察者模式(Observer)
解耦一系列對(duì)象的通知狀態(tài)。定義對(duì)象之間的一對(duì)多依賴，當(dāng)一端對(duì)象發(fā)生變換，通知多端。
3.裝飾模式(Decorator)
動(dòng)態(tài)將責(zé)任附加到對(duì)象上。對(duì)擴(kuò)展開放，對(duì)修改封閉。
4.工廠模式(Factory)
工廠方法：定義一個(gè)創(chuàng)建對(duì)象的接口，由子類實(shí)現(xiàn)這個(gè)接口決定怎樣創(chuàng)建具體類。工廠方法把對(duì)象的創(chuàng)建延遲到子類。
抽象工廠：定義一個(gè)接口，用于創(chuàng)建相關(guān)或依賴對(duì)象的家族，而不明確指定具體類。
5.單例模式(Singleton)
確保一個(gè)類只有一個(gè)實(shí)例，并且提供一個(gè)安全的全局訪問點(diǎn)。
如果對(duì)多線程沒有要求，可以直接在靜態(tài)方法中創(chuàng)建。
如果存在資源競(jìng)爭(zhēng)，采用“餓漢”方式創(chuàng)建。
如果jdk4之后，可有采用double checked locking
6.命令模式(Command)
將請(qǐng)求封裝成對(duì)象，以便使用不同的請(qǐng)求，隊(duì)列或者日志來參數(shù)化其他對(duì)象。
7.適配器模式(Adapter)
改變一個(gè)接口成為一個(gè)客戶端希望的樣子。讓原本不兼容的接口能夠相互合作。
8.外觀模式(Facade)
簡(jiǎn)化系統(tǒng)接口，對(duì)客戶端提供一個(gè)簡(jiǎn)單接口。
9.模板方法模式(Template Method)
在方法中定義一個(gè)算法的骨架，而將一些步驟延遲到子類實(shí)現(xiàn)。使子類在不改變算法結(jié)構(gòu)的情況下，重新定義算法的某些步驟。
10.迭代器模式(Iterator)
提供一種方法順序訪問集合中的每個(gè)元素，而又不暴露其內(nèi)部的表示。
11.組合模式(Composite)
允許你將對(duì)象組成樹形結(jié)構(gòu)來表現(xiàn)“整體/部分”的層次結(jié)構(gòu)。組合能讓客戶端以一致的方式處理個(gè)別對(duì)象和對(duì)象組合。
12.狀態(tài)模式(State)
允許對(duì)象內(nèi)部狀態(tài)改變時(shí)，改變它的行為，對(duì)象看起來就行修改了它的類。
13.代理模式(Proxy)
為對(duì)象提供一個(gè)替身或者占位符來訪問這個(gè)對(duì)象。
14.復(fù)合模式
結(jié)合多個(gè)模式，組成一個(gè)解決方案。
MVC中：
M：觀察者模式
V：組合模式
C：策略模式

總結(jié)

以上是生活随笔為你收集整理的【HeadFirst】设计模式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。