Java進階篇 設計模式之十四 ----- 總結篇

前言

本篇是講述以前學習設計模式的一個總結篇，其目的是爲了對這些設計模式的進行一個提煉總結，可以經過查看看此篇就能夠理解一些設計模式的核心思想。

設計模式簡介

什麼是設計模式

設計模式是一套被反覆使用的、多數人知曉的、通過分類編目的、代碼設計經驗的總結。

爲何使用設計模式

使用設計模式是爲了重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。

設計模式類型

設計模式有23種類型。按照主要分類能夠分爲三大類:

1、建立型模式

這些設計模式提供了一種在建立對象的同時隱藏建立邏輯的方式，而不是使用 new運算符直接實例化對象。這使得程序在判斷針對某個給定實例須要建立哪些對象時更加靈活。

• 單例模式
• 工廠模式
• 抽象工廠模式
• 建造者模式
• 原型模式

2、結構型模式

這些設計模式關注類和對象的組合。繼承的概念被用來組合接口和定義組合對象得到新功能的方式。

• 適配器模式
• 橋接模式
• 過濾器模式
• 組合模式
• 裝飾器模式
• 外觀模式
• 享元模式
• 代理模式

3、行爲型模式

這些設計模式特別關注對象之間的通訊。

• 責任鏈模式
• 命令模式
• 解釋器模式
• 迭代器模式
• 中介者模式
• 備忘錄模式
• 觀察者模式
• 狀態模式
• 空對象模式
• 策略模式
• 模板模式
• 訪問者模式

設計模式的原則

設計模式的六大原則

1. 開閉原則：對擴展開放，對修改關閉。
2. 里氏代換原則：對開閉原則的補充。任何基類能夠出現的地方，子類必定能夠出現。LSP 是繼承複用的基石，只有當派生類能夠替換掉基類，且軟件單位的功能不受到影響時，基類才能真正被複用，而派生類也可以在基類的基礎上增長新的行爲。
3. 依賴倒轉原則：針對接口編程，依賴於抽象而不依賴於具體。
4. 接口隔離原則：儘可能使用多個隔離的接口，爲了下降類之間的耦合度。
5. 迪米特法則：一個實體應當儘可能少地與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。
6. 合成複用原則：儘可能使用合成/聚合的方式，而不是使用繼承。

設計模式之間的關係圖:

設計模式總概況:

設計模式相關文章:

• 單例模式
• 工廠方法和抽象工廠模式
• 建造者模式和原型模式
• 適配器模式和橋接模式
• 外觀模式和裝飾器模式
• 組合模式和過濾器模式
• 享元模式和代理模式
• 責任鏈模式和命令模式
• 解釋器模式和迭代器模式
• 訪問者模式和中介者模式
• 策略模式和模板方法模式
• 觀察者模式和空對象模式

建立型模式

單例模式

單例模式介紹

核心就是保證一個系統中的某個類只有一個實例並且該實例易於外界訪問。

單例模式的使用場景

在程序中比較經常使用的是數據庫鏈接池、線程池、日誌對象等等。

單例模式使用

單例模式的寫法主要有5種，分別是：

• 餓漢式: 簡單安全, 效率低;
• 飽漢式: 簡單不安全, 效率高 ;
• 靜態內部類: 安全, 效率高;
• 雙重鎖檢查: 複雜安全, 效率高;
• 枚舉單例：簡單安全, 效率高；

單例模式示例圖

單例模式總結

1. 構造方法私有化（private）;
2. 定義一個私有(private)靜態(static)實例化對象;
3. 對外提供一個公共(public)靜態(static)的方法獲得該實例;

工廠模式

工廠模式主要有三種，簡單工廠模式、工廠方法模式和抽象工廠模式。可是通常的狀況下咱們主要用到的是工廠方法模式和抽象工廠模式。

工廠方法模式介紹

其核心是定義一個建立對象的接口，讓其子類本身決定實例化哪個工廠類，工廠模式使其建立過程延遲到子類進行。

工廠方法模式使用場景

好比生活中的汽車製造，大名鼎鼎的hibernate框架在選擇數據庫方言這塊。

工廠方法模式示例圖

抽象工廠模式介紹

主要核心是提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類。

抽象工廠模式使用場景

好比生活中的服裝製造廠，能夠單獨製造衣服、褲子、襪子等等，也能夠生產一套服裝。

抽象工廠模式示例圖

建造者模式

建造者模式介紹

使用多個簡單的對象一步一步構建成一個複雜的對象。這種類型的設計模式屬於建立型模式，它提供了一種建立對象的最佳方式。 簡單的來講就是將一個複雜的東西抽離出來，對外提供一個簡單的調用，能夠在一樣的構建過程建立不一樣的表示。和工廠模式很類似，不過相比而言更加註重組件的裝配。

建造者模式使用場景

適用一些基本組件不便，可是組合常常變化的時候。好比超市促銷的大禮包。

建造者模式角色

1. Builder：指定一個抽象的接口，規定該產品所需實現部件的建立，並不涉及具體的對象部件的建立。

2. ConcreteBuilder：需實現Builder接口，而且針對不一樣的邏輯，進行不一樣方法的建立，最終提供該產品的實例。

3. Director：用來建立複雜對象的部分，對該部分進行完整的建立或者按照必定的規則進行建立。

4. Product：示被構造的複雜對象。

建造者模式優缺點

優勢:

1. 建造者獨立，易擴展。
2. 便於控制細節風險。

缺點

1. 內部結構複雜，不易於理解。
2. 產品直接須要有共同點，範圍有控制。

建造者模式示例圖

原型模式

原型模式介紹

用於建立重複的對象，同時又能保證性能。這種類型的設計模式屬於建立型模式，它提供了一種建立對象的最佳方式。核心是克隆。

原型模式使用場景

1. 類初始化的時候須要消耗大量資源的時候；
2. 獲取數據庫鏈接繁瑣的時候；
3. 一個對象，有不少個修改者的時候；

原型模式優缺點

優勢: 1.能夠提高性能；

缺點: 1.由於必須實現Cloneable 接口，因此用起來可能不太方便。

原型模式示例圖

結構型模式

適配器模式

適配器模式介紹

適配器模式是做爲兩個不兼容的接口之間的橋樑。這種類型的設計模式屬於結構型模式，它結合了兩個獨立接口的功能。簡單的來講就是經過某個接口將不兼容的兩個類進行兼容，俗稱轉換器。

適配器模式使用

適配器模式主要有兩種類型，一種是類適配器模式，主要經過繼承來實現適配器功能；一種是對象適配器模式，經過組合來實現適配器功能。

適配器模式使用場景

電器的電壓，經典的jdbc使用。

適配器模式優缺點

優勢:

提高了類的複用和靈活度。

缺點:

使用過多，系統會比較雜亂，難以把握。

適配器模式示例圖

橋接模式

橋接模式介紹

橋接是用於把抽象化與實現化解耦，使得兩者能夠獨立變化。這種類型的設計模式屬於結構型模式，它經過提供抽象化和實現化之間的橋接結構，來實現兩者的解耦。經過一箇中間的橋樑對兩邊的東西進行關聯起來，可是關聯的二者之間又不相互影響。

橋接模式場景

一個類存在兩個獨立變化的維度，且這兩個維度都須要進行擴展。

橋接模式優缺點

優勢:

一、抽象和實現的分離，實現瞭解耦； 二、提高的擴展能力。

缺點:

會使系統看起復雜，對新手不友好，沒有必定的抽象進行設計能力難以理解。

橋接模式示例圖

外觀模式

外觀模式介紹

外觀模式隱藏系統的複雜性，並向客戶端提供了一個客戶端能夠訪問系統的接口。它向現有的系統添加一個接口，來隱藏系統的複雜性。對外提供一個簡單接口，隱藏實現的邏輯。

外觀模式使用場景

系統中有多個複雜的模塊或者子系統的時候。

外觀模式優缺點

優勢:

下降了耦合，從某種方面來講也提高了安全性。

缺點:

不符合開閉原則，不易更改。

外觀模式示例圖

裝飾器模式

裝飾器模式介紹

裝飾器模式容許向一個現有的對象添加新的功能，同時又不改變其結構。這種類型的設計模式屬於結構型模式，它是做爲現有的類的一個包裝。 把某個東西進行裝飾起來，讓它能夠提供一些額外的功能。

裝飾器模式使用場景

原型不變，動態增長一些功能的時候。

裝飾器模式優缺點

優勢:

裝飾類和被裝飾類能夠獨立發展，耦合度低，易於擴展，靈活方便。

缺點:

過多的對某個類進行裝飾，會增長複雜度。

裝飾器模式示例圖

組合模式

組合模式介紹

組合模式是用於把一組類似的對象看成一個單一的對象。組合模式依據樹形結構來組合對象，用來表示部分以及總體層次。這種類型的設計模式屬於結構型模式，它建立了對象組的樹形結構。

組合模式使用場景

能夠表示爲 ‘部分-總體’的層級結構。

組合模式優缺點

優勢:

高層模塊調用較爲簡單，增長某個節點方便。

缺點:

由於其子節點的聲明都是實現類，而不是接口，違反了依賴倒置原則。

組合模式示例圖

過濾器模式

過濾器模式介紹

過濾器模式容許開發人員使用不一樣的標準來過濾一組對象，經過邏輯運算以解耦的方式把它們鏈接起來。這種類型的設計模式屬於結構型模式，它結合多個標準來得到單一標準。

過濾器模式使用場景

須要進行篩選的時候。

過濾器模式優缺點

優勢：

簡單，解耦，使用方便。

缺點：

過多使用須要注意性能。

過濾器模式注意事項

在jdk1.8之後可使用steam的方法進行過濾分組，能夠根據指定的條件進行過濾分組篩選。

享元模式

享元模式介紹

享元模式主要用於減小建立對象的數量，以減小內存佔用和提升性能。這種類型的設計模式屬於結構型模式，它提供了減小對象數量從而改善應用所需的對象結構的方式。

享元模式角色

享元模式的角色主要分爲三大類，抽象享元類、具體享元類以及享元工廠類。

• 抽象享元類：全部具體享元類的超類或者接口，經過這個接口，能夠接受並做用於外部專題。
• 具體享元類：實現抽象享元類接口的功能並增長存儲空間。
• 享元工廠類：用來建立並管理抽象享元類對象，它主要用來確保合理地共享。每當接受到一個請求是，便會提供一個已經建立的抽象享元類對象或者新建一個。 享元模式的核心在於享元工廠類，享元工廠類的做用在於提供一個用於存儲享元對象的享元池，用戶須要對象時，首先從享元池中獲取，若是享元池中不存在 ，則建立一個新的享元對象返回給用戶，並在享元池中保存該新增對象。

享元模式使用場景

系統有大量類似對象。

享元模式優缺點

優勢：

極大的減小對象的建立，從而下降了系統的內存，提高了效率。

缺點：

提升了系統的複雜度，由於須要將狀態進行分離成內部和外部，而且也使外部狀態固有化，使得隨着內部狀態的變化而變化，會形成系統的混亂。

享元模式注意事項

須要注意劃分外部狀態和內部狀態，不然可能會引發線程安全問題。 這些類必須有一個工廠對象加以控制。

與單例模式比較

雖然它們在某些方面很像，可是實際上倒是不一樣的東西，單例模式的目的是限制建立多個對象，避免衝突，好比使用數據庫鏈接池。而享元模式享元模式的目的是共享，避免屢次建立耗費資源，好比使用String類。

享元模式示例圖

代理模式

代理模式介紹

主要是經過一個類表明另外一個類的功能。一般，咱們建立具備現有對象的對象，以便向外界提供功能接口。

代理模式角色

代理模式主要由這三個角色組成，抽象角色、代理角色和真實角色。

• 抽象角色：經過接口或抽象類聲明真實角色實現的業務方法。
• 代理角色：實現抽象角色，是真實角色的代理，經過真實角色的業務邏輯方法來實現抽象方法，並能夠附加本身的操做。
• 真實角色：實現抽象角色，定義真實角色所要實現的業務邏輯，供代理角色調用。

代理模式使用

代理模式又分爲靜態代理、動態代理。

• 靜態代理是由程序員建立或工具生成代理類的源碼，再編譯代理類。所謂靜態也就是在程序運行前就已經存在代理類的字節碼文件，代理類和委託類的關係在運行前就肯定了。
• 動態代理是在實現階段不用關心代理類，而在運行階段才指定哪個對象。可使用JDK中java.lang.reflect來進行開發。

代理模式使用場景

一、遠程代理。 二、虛擬代理。 三、Copy-on-Write 代理。 四、保護（Protect or Access）代理。 五、Cache代理。 六、防火牆（Firewall）代理。 七、同步化（Synchronization）代理。 八、智能引用（SmartReference）代理。

代理模式優缺點

優勢：

一、職責清晰。 二、高擴展性。 三、智能化。

缺點：

一、因爲在客戶端和真實主題之間增長了代理對象，所以有些類型的代理模式可能會形成請求的處理速度變慢。 二、實現代理模式須要額外的工做，有些代理模式的實現很是複雜。

代理模式注意事項

和適配器模式的區別：適配器模式主要改變所考慮對象的接口，而代理模式不能改變所代理類的接口。 和裝飾器模式的區別：裝飾器模式爲了加強功能，而代理模式是爲了加以控制。

代理模式示例圖

行爲型模式

責任鏈模式

責任鏈模式介紹

責任鏈模式顧名思義，就是爲請求建立了一個接收者對象的鏈。這種模式給予請求的類型，對請求的發送者和接收者進行解耦。這種類型的設計模式屬於行爲型模式。在這種模式中，一般每一個接收者都包含對另外一個接收者的引用。若是一個對象不能處理該請求，那麼它會把相同的請求傳給下一個接收者，依此類推。 簡單的理解的話就是進行層級處理。

責任鏈模式角色

責任鏈模式主要由這三個角色組成，請求接收者接口(Handler)、請求實現者類(ConcreteHandler)和請求發送者(Client)。

• 請求接收者接口：定義能夠處理客戶端請求事項的接口，包含「可連接下一個一樣能處理請求」的對象引用。
• 請求實現者類：實現請求處理接口，並判斷對象自己是否可以處理本次請求，若是不能完成請求，則交由後繼者來處理。
• 請求發送者：將請求發送給第一個接收者對象，並等待請求的回覆。

責任鏈模式使用場景

須要動態指定處理某一組請求時，在不肯定接受者的的狀況下，向多個對象發送請求時。

責任鏈模式優缺點

優勢：

耦合度低，請求者和執行者並無必然的聯繫； 靈活度高，能夠經過內部成員來進行更改它們執行的次序； 擴展性好，Handler的子類擴展很是方便。

缺點：

會在某程度上下降程序的性能，設置不當的話可能會出現循環調用。 在鏈過長時，會下降代碼的閱讀性以及增長代碼的複雜度。

責任鏈模式注意事項

雖然責任鏈模式很靈活，可是犧牲的是必定的性能，由於責任鏈模式是層級處理，在處理數據的有必定的延遲，所因此須要低延遲的狀況下，不推薦使用責任鏈模式。

責任鏈模式示例圖

命令模式

命令模式介紹

命令模式顧名思義，是一種數據驅動的設計模式，它屬於行爲型模式。請求以命令的形式包裹在對象中，並傳給調用對象。調用對象尋找能夠處理該命令的合適的對象，並把該命令傳給相應的對象，該對象執行命令。 也就是將一個請求封裝成一個對象，從而能夠用不一樣的請求對客戶進行參數化。

命令模式角色

命令模式主要由這三個角色組成，命令對象(command)、命令執行對象(received)和命令請求對象(invoker)。

• 命令對象：經過接口或抽象類聲明實現的方法。
• 命令執行對象：實現命令對象的方法，並將一個接收者和動做進行綁定，調用接收者相應的操做。
• 命令請求對象：用於執行這個請求，能夠動態的對命令進行控制。

命令模式使用場景

若是在有相似命令須要指定的，就能夠用命令模式，好比記錄日誌、撤銷操做命令等。

命令模式優缺點

優勢：

耦合度低，請求者和執行者並無必然的聯繫； 擴展性好，Command的子類能夠很是容易地擴展。

缺點：

若是命令過多的話，會增長系統的複雜度 。

命令模式示例圖

解釋器模式

解釋器模式介紹

解釋器模式顧名思義，就是對某事物進行解釋。給定一個語言以後，解釋器模式能夠定義出其文法的一種表示，並同時提供一個解釋器。客戶端可使用這個解釋器來解釋這個語言中的句子。 解釋器模式其實就是對某事物進行解釋。

解釋器模式角色

解釋器模式主要由這四個角色組成，抽象表達式(Expression)角色、終結符表達式(Terminal Expression)角色、非終結符表達式(Nonterminal Expression)角色和環境(Context)角色。

• 抽象解釋器：聲明一個全部具體表達式都要實現的抽象接口（或者抽象類），接口中主要是一個interpret()方法，稱爲解釋操做。具體解釋任務由它的各個實現類來完成，具體的解釋器分別由終結符解釋器TerminalExpression和非終結符解釋器NonterminalExpression完成。
• 終結符表達式：實現與文法中的元素相關聯的解釋操做，一般一個解釋器模式中只有一個終結符表達式，但有多個實例，對應不一樣的終結符。終結符一半是文法中的運算單元，好比有一個簡單的公式R=R1+R2，在裏面R1和R2就是終結符，對應的解析R1和R2的解釋器就是終結符表達式。
• 非終結符表達式：文法中的每條規則對應於一個非終結符表達式，非終結符表達式通常是文法中的運算符或者其餘關鍵字，好比公式R=R1+R2中，+就是非終結符，解析+的解釋器就是一個非終結符表達式。非終結符表達式根據邏輯的複雜程度而增長，原則上每一個文法規則都對應一個非終結符表達式。
• 環境角色：這個角色的任務通常是用來存放文法中各個終結符所對應的具體值，好比R=R1+R2，咱們給R1賦值100，給R2賦值200。這些信息須要存放到環境角色中，不少狀況下咱們使用Map來充當環境角色就足夠了。

解釋器模式使用場景

一個簡單的語法規則須要解釋的場景，好比sql。 有重複的問題的時候。

解釋器模式優缺點

優勢：

擴展性好，子類擴展很是方便。 實現簡單。

缺點：

可以使用的場景比較少； 類過多的話，會使代碼臃腫，難以維護；

解釋器模式示例圖

迭代器模式

迭代器模式介紹

迭代器模式用於順序訪問集合對象的元素，不須要知道集合對象的底層表示，屬於行爲型模式。 它提供一種方法順序訪問一個聚合對象中各個元素, 而又無須暴露該對象的內部表示。

迭代器模式角色

迭代器模式主要由這四個角色組成，迭代器角色（Iterator）、具體迭代器角色（Concrete Iterator）、容器角色（Container）和具體容器角色（Concrete Container）。

• 迭代器角色（Iterator）：經過接口或抽象類聲明實現的方法。
• 具體迭代器角色（Concrete Iterator）：具體迭代器角色要實現迭代器接口，並要記錄遍歷中的當前位置。
• 容器角色（Container）：容器角色負責提供建立具體迭代器角色的接口。
• 具體容器角色（Concrete Container）：具體容器角色實現建立具體迭代器角色的接口——這個具體迭代器角色於該容器的結構相關。

迭代器模式使用場景

須要爲聚合對象提供遍歷的功能的時候。

迭代器模式優缺點

優勢：

靈活度高，能夠經過不一樣的方式遍歷對象； 擴展性好，能夠很方便的增長新的聚合類和迭代器類而不用修改以前的代碼。

缺點：

因爲迭代器模式將存儲數據和遍歷數據的職責分離，增長新的聚合類須要對應增長新的迭代器類，類的個數成對增長，這在必定程度上增長了系統的複雜性。

迭代器模式示例圖

訪問者模式

訪問者模式介紹

訪問者模式（VisitorPattern），顧名思義使用了這個模式後就能夠在不修改已有程序結構的前提下，經過添加額外的訪問者來完成對已有代碼功能的提高，它屬於行爲模式。訪問者模式的目的是封裝一些施加於某種數據結構元素之上的操做。一旦這些操做須要修改的話，接受這個操做的數據結構則能夠保持不變。 其主要目的是將數據結構與數據操做分離。

訪問者模式角色

訪問者模式主要由這五個角色組成，抽象訪問者(Visitor)、具體訪問者(ConcreteVisitor)、抽象節點(Node)、具體節點(ConcreteNode)和結構對象(ObjectStructure)。

• 抽象訪問者(Visitor)角色：聲明瞭一個或者多個方法操做，造成全部的具體訪問者角色必須實現的接口。
• 具體訪問者(ConcreteVisitor)角色：實現抽象訪問者所聲明的接口，也就是抽象訪問者所聲明的各個訪問操做。
• 抽象節點(Node)角色：聲明一個接受操做，接受一個訪問者對象做爲一個參數。
• 具體節點(ConcreteNode)角色：實現了抽象節點所規定的接受操做。
• 結構對象(ObjectStructure)角色：有以下的責任，能夠遍歷結構中的全部元素。

訪問者模式使用場景

對象結構中對象對應的類不多改變，但常常須要在此對象結構上定義新的操做； 須要對一個對象結構中的對象進行不少不一樣的而且不相關的操做，而須要避免讓這些操做"污染"這些對象的類，也不但願在增長新操做時修改這些類。

訪問者模式優缺點

訪問者模式優勢：

擴展性好，能夠在不修改對象結構中的元素的狀況下，爲對象結構中的元素添加新的功能； 符合單一職責原則，經過訪問者將無關的行爲分離，使職責單一；

訪問者模式缺點：

違反了迪米特原則，由於具體元素對訪問者公佈細節； 違反了依賴倒置原則，依賴了具體類，沒有依賴抽象； 對象結構變化困難，若對象結構發生了改變，訪問者的接口和訪問者的實現也都要發生相應的改變；

訪問者模式示例圖

中介者模式

中介者模式介紹

中介者模式（Mediator Pattern），定義了一箇中介對象來封裝一系列對象之間的交互關係。中介者使各個對象之間不須要顯式地相互引用，從而使耦合性下降，並且能夠獨立地改變它們之間的交互行爲，屬於行爲型模式。 其主要的目的是用來下降多個對象和類之間的通訊複雜性。

中介者模式角色

中介者模式主要由這四個角色組成， 抽象中介者(Mediator)、具體中介者(ConcreteMediator)、 抽象同事類(Colleague)和具體同事類(ConcreteColleague) 。

• 抽象中介者(Mediator): 定義了同事對象到中介者對象之間的接口。
• 具體中介者(ConcreteMediator): 實現抽象中介者的方法，它須要知道全部的具體同事類，同時須要從具體的同事類那裏接收信息，而且向具體的同事類發送信息。
• 抽象同事類(Colleague): 定義了中介者對象的接口，它只知道中介者而不知道其餘的同事對象。
• 具體同事類(ConcreteColleague) : 每一個具體同事類都只須要知道本身的行爲便可，可是他們都須要認識中介者。

中介者模式使用場景

經過一箇中間類來封裝多個類中的行爲，而又不想生成太多的子類。

中介者模式優缺點

優勢：

靈活性高，由於將同事類進行了解耦，使其沒必要有關聯性； 下降了類的複雜度，將一對多轉化成了一對一；

缺點：

中介者使用過多，會使系統變得複雜難以維護；

中介者模式注意事項

若不明確各個類的職責，那麼就不要進行使用！

和外觀模式、代理模式比較

中介者模式和外觀模式、代理模式比較相似，可是又有不一樣。 和外觀模式比較，中介者模式中，同事類必須依賴與中介者，中介者也知道同事類；可是外觀模式中，子系統是不須要知道外觀類的存在，而且子系統是能夠脫離外觀模式的。 和代理模式，代理模式的核心就是代理做用，主要仍是對原先的類進行擴展或增長控制，好比進行權限控制；而中介者模式主要目的是爲了減小對象以前的耦合，也就是同事類直接相互獨立，互不影響。

中介者模式示例圖

策略模式

策略模式介紹

策略模式（Strategy Pattern）屬於對象的行爲模式。其用意是針對一組算法，將每個算法封裝到具備共同接口的獨立的類中，從而使得它們能夠相互替換。策略模式使得算法能夠在不影響到客戶端的狀況下發生變化。 其主要目的是經過定義類似的算法，替換if else 語句寫法，而且能夠隨時相互替換。

策略模式角色

策略模式主要由這三個角色組成，環境角色(Context)、抽象策略角色(Strategy)和具體策略角色(ConcreteStrategy)。

• 環境角色(Context)：持有一個策略類的引用，提供給客戶端使用。
• 抽象策略角色(Strategy)：這是一個抽象角色，一般由一個接口或抽象類實現。此角色給出全部的具體策略類所需的接口。
• 具體策略角色(ConcreteStrategy)：包裝了相關的算法或行爲。

策略模式使用場景

若是在一個系統裏面有許多類，它們之間的區別僅在於它們的行爲，那麼使用策略模式能夠動態地讓一個對象在許多行爲中選擇一種行爲； 一個系統須要動態地在幾種算法中選擇一種; 若是一個對象有不少的行爲，若是不用恰當的模式，這些行爲就只好使用多重的條件選擇語句來實現;

策略模式優缺點

優勢：

擴展性好，能夠在不修改對象結構的狀況下，爲新的算法進行添加新的類進行實現； 靈活性好，能夠對算法進行自由切換；

缺點：

使用策略類變多，會增長系統的複雜度。； 客戶端必須知道全部的策略類才能進行調用；

策略模式示例圖

模板模式

模板模式介紹

模板模式（Template Pattern）中，一個抽象類公開定義了執行它的方法的方式/模板。它的子類能夠按須要重寫方法實現，但調用將以抽象類中定義的方式進行。 這種類型的設計模式屬於行爲型模式。定義一個操做中的算法的骨架，而將一些步驟延遲到子類中。 模板模式，其主要的的思想就是作一個模板，提供給客戶端進行調用。

模板模式角色

模板模式主要由抽象模板(Abstract Template)角色和具體模板(Concrete Template)角色組成。

• 抽象模板(Abstract Template): 定義了一個或多個抽象操做，以便讓子類實現。這些抽象操做叫作基本操做，它們是一個頂級邏輯的組成步驟;定義並實現了一個模板方法。這個模板方法通常是一個具體方法，它給出了一個頂級邏輯的骨架，而邏輯的組成步驟在相應的抽象操做中，推遲到子類實現。頂級邏輯也有可能調用一些具體方法。

• 具體模板(Concrete Template): 實現父類所定義的一個或多個抽象方法，它們是一個頂級邏輯的組成步驟;每個抽象模板角色均可以有任意多個具體模板角色與之對應，而每個具體模板角色均可以給出這些抽象方法（也就是頂級邏輯的組成步驟）的不一樣實現，從而使得頂級邏輯的實現各不相同。

模板模式使用場景

有多個子類共有邏輯相同的方法； 重要的、複雜的方法，能夠考慮做爲模板方法。

模板模式優缺點

優勢：

擴展性好，對不變的代碼進行封裝，對可變的進行擴展； 可維護性好，由於將公共代碼進行了提取，使用的時候直接調用便可；

缺點：

由於每個不一樣的實現都須要一個子類來實現，致使類的個數增長，會使系統變得複雜；

模板模式注意事項

爲防止惡意操做，通常模板方法都加上 final 關鍵詞！

模板模式示例圖

備忘錄模式

備忘錄模式介紹

備忘錄模式(Memento Pattern)用於保存一個對象的某個狀態，以便在適當的時候恢復對象，該模式屬於行爲型模式。 其主要目的是在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態。 其主要的的思想就是備份。

備忘錄模式角色

備忘錄模式主要由這三個角色組成，備忘錄角色(Memento)、發起人角色(Originator)和負責人(Caretaker)角色。

• 備忘錄(Memento)：主要的功能是包含要被恢復的對象的狀態。
• 發起人(Originator)：在建立的時候，會在備忘錄對象中存儲狀態。
• 負責人(Caretaker)：主要是負責從備忘錄對象中恢復對象的狀態。

備忘錄模式使用場景

須要保存/恢復數據的相關狀態場景；

備忘錄模式優缺點

優勢

給用戶提供了一種能夠恢復狀態的機制，可使用戶可以比較方便地回到某個歷史的狀態； 實現了信息的封裝，使得用戶不須要關心狀態的保存細節；

缺點

很是的消耗資源； 客戶端必須知道全部的策略類才能進行調用；

備忘錄模示例圖

狀態模式

狀態模式介紹

狀態模式（State Pattern）屬於行爲型模式，其狀態的對象和一個行爲隨着狀態對象改變而改變。 其主要目的解決的是當控制一個對象狀態轉換的條件表達式過於複雜是的狀況。把狀態的判斷邏輯轉移到表示不一樣狀態一系列類中，能夠把複雜的判斷簡單化。 主要的的思想就是提供一種狀態，提供給客戶端進行調用。

狀態模式角色

狀態模式主要由環境角色（Context）、 抽象狀態（State）和具體狀態（Concrete State）組成。

• 環境角色（Context）: 它定義了客戶程序須要的接口並維護一個具體狀態角色的實例，將與狀態相關的操做委託給當前的具體狀態對象來處理。

• 抽象狀態角色(State): 定義一個接口以封裝使用上下文環境的的一個特定狀態相關的行爲。

• 具體狀態角色（Concrete State）:實現抽象狀態定義的接口。

狀態模式使用場景

行爲隨狀態改變而改變的場景； 條件、分支語句的代替者。

狀態模式優缺點

優勢：

擴展性好，將和狀態有關的行爲放到一塊兒，增長新的的狀態，只須要改變對象狀態便可改變對象的行爲便可； 複用性好，讓多個環境對象共享一個狀態對象，從而減小系統中對象的個數；

缺點：

使用狀態模式會增長系統類和對象的個數，而且該模式的結構與實現都較爲複雜，若是使用不當將致使程序結構和代碼的混亂； 狀態模式對"開閉原則"的支持並不太好，對於能夠切換狀態的狀態模式，增長新的狀態類須要修改那些負責狀態轉換的源代碼，不然沒法切換到新增狀態，並且修改某個狀態類的行爲也需修改對應類的源代碼。

狀態模式注意事項

在行爲受狀態約束的時候使用狀態模式，並且狀態不超過5個。

和策略模式比較 在學習狀態模式的時候，很容易和策略模式搞混，由於它們實在是太像了，很難區分，在查閱一番資料以後，整理了以下的相同點和區別點。

相同點:

1. 它們很容易添加新的狀態或策略，並且不須要修改使用它們的Context對象。
2. 它們都符合OCP原則，在狀態模式和策略模式中，Context對象對修改是關閉的，添加新的狀態或策略，都不須要修改Context。
3. 它們都會初始化。
4. 它們都依賴子類去實現相關行爲。

區別點

1. 狀態模式的行爲是平行性的，不可相互替換的；
2. 而策略模式的行爲是平等性的，是能夠相互替換的。
3. 最重要的一個不一樣之處是，策略模式的改變由客戶端完成；
4. 而狀態模式的改變，由環境角色或狀態本身.

狀態模式示例圖

觀察者模式

觀察者模式介紹

觀察者模式又叫發佈-訂閱(Publish/Subscribe)模式、模型-視圖(Model/View)模式、源-監聽器(Source/Listener)模式或從屬者(Dependents)模式。觀察者模式定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時，會通知全部觀察者對象，使它們可以自動更新本身。。 其主要目的是定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並被自動更新。

觀察者模式角色

觀察者模式主要由這四個角色組成，抽象主題角色（Subject）、具體主題角色（ConcreteSubject）、抽象觀察者角色（Observer）和具體觀察者角色（ConcreteObserver）。

• 抽象主題角色（Subject）：它把全部觀察者對象的引用保存到一個彙集裏，每一個主題均可以有任何數量的觀察者。抽象主題提供一個接口，能夠增長和刪除觀察者對象。
• 具體主題角色（ConcreteSubject）：將有關狀態存入具體觀察者對象；在具體主題內部狀態改變時，給全部登記過的觀察者發出通知。
• 抽象觀察者角色（Observer）：主要是負責從備忘錄對象中恢復對象的狀態。

觀察者模式使用場景

須要關聯行爲的場景； 事件須要建立一個觸發鏈的場景，好比監控； 跨系統的消息交換場景，好比消息隊列、事件總線的處理機制。

觀察者模式優缺點

優勢:

解除耦合，讓耦合的雙方都依賴於抽象，從而使得各自的變換都不會影響另外一邊的變換。

缺點

若是一個被觀察者對象有不少的直接和間接的觀察者的話，將全部的觀察者都通知到會花費不少時間； 若是在觀察者和觀察目標之間有循環依賴的話，觀察目標會觸發它們之間進行循環調用，可能致使系統崩潰； 觀察者模式沒有相應的機制讓觀察者知道所觀察的目標對象是怎麼發生變化的，而僅僅只是知道觀察目標發生了變化。

觀察者模式注意事項

若是順序執行，某一觀察者錯誤會致使系統卡殼，建議採用異步方式。

觀察者模式示例圖

空對象模式

空對象模式介紹

空對象模式（NullObject Pattern）主要是經過一個空對象取代 NULL 對象實例的檢查。Null 對象不是檢查空值，而是反應一個不作任何動做的關係。 這樣的Null 對象也能夠在數據不可用的時候提供默認的行爲。 其主要目的是在進行調用是不返回Null，而是返回一個空對象，防止空指針異常。

空對象模式使用場景

須要大量對空值進行判斷的時候；

空對象模式優缺點

優勢：

能夠增強系統的穩固性，能有效防止空指針報錯對整個系統的影響； 不依賴客戶端即可以保證系統的穩定性；

缺點：

須要編寫較多的代碼來實現空值的判斷，從某種方面來講不划算；

其它

在學習設計模式的時候，主要參考書籍是《大話設計模式》以及菜鳥教程的設計模式介紹。 其實在咱們學習了這麼多的設計模式中，大部分可能只是據說瞭解過，真正常用的設計模式也無外乎就那幾種，單例模式(數據庫、線程池場景)、工廠模式(簡單的crud操做中實例化的model)、策略模式(商城會員、優惠打折場景)、觀察者模式(消息推送場景)、代理模式（主要是動態代理這塊)、外觀模式(一鍵調用)、裝飾器模式(錦上添花場景)，可是也不全這樣，使用設計模式最好根據實際的場景來使用，不然可能在不合適的場景使用了不適合的設計模式而致使代碼混亂。

音樂推薦

往期音樂推薦

1、

咱們目送 那漸漸消失的行跡雲 在晃眼間消逝 老是如此短暫 如像昨天起 不變的事 始終不會改變 不應存在的東西 帶着遺憾消失在指間 那鳥兒還未能展翅高飛 但它總有一天會破風馳行 高不可攀的地方仍在遠處 因此只能凝視深藏的願望 孩子們走在盛夏的鐵路上 流風輕撫着他們的赤腳 遠離了童年

2、

這世上大部分失落，都是由於咱們本身沒成爲更好的本身，卻奢求別人成爲更好的別人。

3、

平靜孤寂的調子起頭，兩我的分開以後的沉寂 頹廢，慢慢的音階起伏，我意識到不能這樣下去，我開始改變現狀，變得積極。到高潮部分 我不在頹廢，我走了新的目標 我迎着太陽前進。我想這就是You的含義，你是個人一段過去

4、

扶桑畫師淺溪，居泰安，喜繪鯉。院前一方荷塘，錦鯉遊曳，溪常與嬉戲。 其時正武德之亂，藩鎮割據，戰事頻仍，魑魅魍魎，肆逆於道。兵戈逼泰安，街鄰皆逃亡，獨溪不捨錦鯉，未去。 是夜，院室倏火。有人入火護溪，言其本鯉中妖，欲取溪命，卻生情愫，遂不忍爲之。翌日天明，火勢漸歇，人已不見。

5、

稚兒擎瓜柳棚下，細犬逐蝶窄巷中，人間繁華多笑語，唯我空餘兩鬢風。

6、

散落的花，火的碎片 誘人的夏夜終結 漸漸 天空閃耀，帶着誰許的願 忽然綻開的煙花 美麗如夢幻，遲來脆弱的夏天 夜空中，火花舞動在今夜 枝頭落下的仲夏夜之夢 愉快的涼風，熱帶的夜 天空飄着細雨，在喧鬧的蟬鳴時節 夏末，秋天指向路邊。

7、

論如何一我的在家嗨成狗。取下耳機無限的孤獨感。帶上耳機臥槽我是全世界。

8、

我渴望能見你一面，但請你記得，我不會開口要求見你。這不是由於驕傲，你知道我在你面前毫無驕傲可言，而是由於，惟有你也想見個人時候，咱們見面纔有意義。 ———《越洋情書》

9、

就算是Believe，中間也藏了一個lie； 就算是Friend，仍是免不了end； 就算是Lover，還可能會over； 就算是Wife，內心也夾雜着if； 欣慰的是：即使是Forget，也曾經get， 就算impossible，但還藏着possible。

10、

人有三樣東西是沒法隱瞞的，咳嗽、窮困和愛；你想隱瞞越此地無銀三百兩。人有三樣東西是不應揮霍的，身體、金錢和愛；你想揮霍卻得不償失。人有三樣東西是沒法挽留的，時間、生命和愛；你想挽留卻漸行漸遠。人有三樣東西是不應回憶的，災難、死亡和愛；你想回憶卻苦不堪言。 ——《洛麗塔》

11、

簡單，重複，毫無華麗旋律，也無厚重悲涼的伴奏。但心恰恰就被牢牢的抓住了。一種茫然卻被迫緊湊的感受。一種不知何所處的心虛。what for？

12、

輕吟一句情話，執筆一副情畫。 綻開一地情花，覆蓋一片青瓦。 共飲一杯清茶，同研一碗青砂。 挽起一面輕紗，看清天邊月牙。愛像水墨青花，何懼剎那芳華。

十3、

全部人和事，本身心安理得就好，不是你的也彆強求，反正離去的，都是風景，留下的，纔是人生。

以上評論來自網易雲！

項目的代碼

java-study 是本人在學習Java過程當中記錄的一些代碼，也包括以前博文中使用的代碼。若是感受不錯，但願順手給個start，固然若是有不足，也但願提出。 github地址: github.com/xuwujing/ja…

原創不易，若是感受不錯，但願給個推薦！您的支持是我寫做的最大動力！ 版權聲明: 做者：虛無境
博客園出處：www.cnblogs.com/xuwujing CSDN出處：blog.csdn.net/qazwsxpcm  我的博客出處：www.panchengming.com