開端-Java設(shè)計(jì)模式導(dǎo)讀

和往常一樣，本篇文章依舊采用“3W”順序（即What,Why和Where）來回答軟件工程中的設(shè)計(jì)模式是什么，為什么需要設(shè)計(jì)模式以及在什么地方使用設(shè)計(jì)模式這三個問題。

​本篇文章時Java設(shè)計(jì)模式系列技術(shù)文章的開篇，作為導(dǎo)讀文章，將快速地對設(shè)計(jì)模式的基本概念、模式分類和適用范圍進(jìn)行解讀。在后續(xù)的章節(jié)中，將對每一種類別的設(shè)計(jì)模式進(jìn)行詳細(xì)的講解，講解的內(nèi)容包括每種設(shè)計(jì)模式的基本原理、適用范圍和實(shí)戰(zhàn)案例剖析三個部分。

1 模式的基本概念

​ 模式是指解決某個特定領(lǐng)域問題，實(shí)現(xiàn)既定目標(biāo)的方法或思想。具體來說，模式是那些身處于某個行業(yè)的從業(yè)人員根據(jù)實(shí)際的工作經(jīng)驗(yàn)總結(jié)出的，具有通用性的且被行業(yè)公認(rèn)的解決問題的方法或流程。模式并非只在軟件工程中被應(yīng)用，其在日常的生產(chǎn)活動中被廣泛地使用，如制造業(yè)，餐飲業(yè)，建筑設(shè)計(jì)、醫(yī)療衛(wèi)生、教育培訓(xùn)以及軟件工程等都有模式的身影。

2 什么是設(shè)計(jì)模式？

​ 首先，設(shè)計(jì)模式是一種模式。在軟件工程中，設(shè)計(jì)模式是一種通用的、可重復(fù)使用的用于解決既定范圍內(nèi)普遍發(fā)生的重復(fù)性問題的軟件設(shè)計(jì)方法。使用成熟可靠的設(shè)計(jì)模式，可以提高代碼復(fù)用性，節(jié)省開發(fā)時間，從而實(shí)現(xiàn)功能更強(qiáng)大、高度可維護(hù)的代碼。這有助于降低軟件產(chǎn)品的總體擁有成本，即TCO(Total Cost of Ownership)。另一方面，由于采用了統(tǒng)一的標(biāo)準(zhǔn)設(shè)計(jì)方法(思想或理論知識)，可以顯著提升開發(fā)團(tuán)隊(duì)的生產(chǎn)效率和協(xié)作能力。

3 Java設(shè)計(jì)模式的分類

​ 在Java編程語言中，常用的設(shè)計(jì)模式可分為三種類型：

• 建造類設(shè)計(jì)模式：主要用于定義和約束如何創(chuàng)建一個新的對象
• 結(jié)構(gòu)類設(shè)計(jì)模式：主要用于定義如何使用多個對象組合出一個或多個復(fù)合對象
• 行為類設(shè)計(jì)模式：主要用于定義和描述對象之間的交互規(guī)則和限定對象的職責(zé)邊界線

圖3-1 設(shè)計(jì)模式分類

3.1 建造類設(shè)計(jì)模式

​ 建造類共包括五（5）種基本設(shè)計(jì)模式：單例模式，工廠模式，抽象工廠模式，建造器模式和原型模式，如圖3-2所示：

圖3-2 建造類設(shè)計(jì)模式

3.2 結(jié)構(gòu)類設(shè)計(jì)模式

​ 結(jié)構(gòu)類共包括八（8）種基本設(shè)計(jì)模式：適配器模式，組合模式，代理模式，享元模式，過濾器模式，橋接模式，修飾模式和外觀模式，如圖3-3所示：

圖3-3 結(jié)構(gòu)類設(shè)計(jì)模式

3.3 行為類設(shè)計(jì)模式

​ 行為類共包括十一（11）種基本設(shè)計(jì)模式：模板方法模式，解釋器模式，責(zé)任鏈模式，觀察者模式，戰(zhàn)略模式，命令模式，狀態(tài)模式，訪客模式，轉(zhuǎn)義模式，迭代器模式和備忘錄模式，如圖3-4所示：

圖3-4 行為類設(shè)計(jì)模式

​ 設(shè)計(jì)模式不僅僅只有上述描述的這三大類，除此之外還有許多的設(shè)計(jì)模式?，F(xiàn)已知的設(shè)計(jì)模式還有100多種，如DAO模式，依賴注入模式和MVC模式等。

4 快速理解設(shè)計(jì)模式

​ 在接下來的內(nèi)容中，將快速對Java中常見的24中設(shè)計(jì)模式的基本概念進(jìn)行梳理，以求對各種設(shè)計(jì)模式的原理和適用范圍有一個大致的認(rèn)識。

4.1 建造類

​ 建造類設(shè)計(jì)模式提供了對創(chuàng)建對象的基本定義和約束條件，以尋求***的實(shí)例化Java對象解決方案。

4.1.1 單例模式-Singleton

​ 單例模式限制類的實(shí)例化過程，以確保在Java虛擬機(jī)（JVM）中有且只有一個類的實(shí)例化對象。單例模式是Java中最常用，也是最簡單的設(shè)計(jì)模式之一。單例模式通常需具備如下的幾個特征：

• 單例模式限制類的實(shí)例化，且Java虛擬機(jī)中只能存在一個該類的示例化對象
• 單例模式必須提供一個全局可用的訪問入口來獲取該類的實(shí)例化對象
• 單例模式常被用于日志記錄，驅(qū)動程序?qū)ο笤O(shè)計(jì)，緩存以及線程池
• 單例模式也會被用于其他的設(shè)計(jì)模式當(dāng)中，如抽象工廠模式，建造者模式，原型模式等

單例模式的Java類的內(nèi)部結(jié)構(gòu)如圖4-1所示：

圖4-1 單例模式類圖

下面是單例模式的一份示例代碼清單：

4.1.2 工廠模式-Factory

​ 在Java程序設(shè)計(jì)過程中，當(dāng)一個超類(super class)具有多個子類(sub class)，且需要頻繁的創(chuàng)建子類對象時，我們可以采用工廠模式。工廠模式的作用是將子類的實(shí)例化工作統(tǒng)一交由工廠類來完成，通過對輸入?yún)?shù)的判斷，工廠類自動實(shí)例化具體的子類。實(shí)現(xiàn)工廠模式需要滿足三個條件：

• 超類（super class）：超類是一個抽象類
• 子類（sub class）: 子類需繼承超類
• 工廠類（factory class）:工廠類根據(jù)輸入?yún)?shù)實(shí)例化子類

圖4-2為Java工廠模式的類圖：

圖4-2 工廠模式UML類圖

下面是工廠模式的一份示例代碼清單：

4.1.3 抽象工廠模式-Abstract Factory

​ 抽象工廠模式與工廠模式很類似，抽象工廠模式可以簡單的理解為“工廠的工廠”。在工廠模式中，根據(jù)提供的輸入?yún)?shù)返回產(chǎn)品類的實(shí)例化對象，這個過程需要通過if-else或者switch這樣的邏輯判斷語句來完成具體子類的判定。而在抽象工廠模式中，每種產(chǎn)品都有具體的工廠類與之對應(yīng)，從而避免在編碼過程中使用大量的邏輯判斷代碼。抽象工廠模式會根據(jù)輸入的工廠類型以返回具體的工廠子類。抽象工廠類只負(fù)責(zé)實(shí)例化工廠子類，不參與商品子類的實(shí)例化工作。圖4-3是抽象工廠模式的UML類圖：

圖4-3 抽象工廠模式

4.1.4 建造器模式-Builder

​ 建造者模式通常被用于需要多個步驟創(chuàng)建對象的場景中。建造者模式的主要意圖是將類的構(gòu)建邏輯轉(zhuǎn)移到類的實(shí)例化之外，當(dāng)一個類有許多的屬性，當(dāng)在實(shí)例化該類的對象時，并不一定擁有該實(shí)例化對象的全部屬性信息，便可使用建造者模式通過逐步獲取實(shí)例化對象的屬性信息，來完成該類的實(shí)例化過程。而工廠模式和抽象工廠模式需要在實(shí)例化時獲取該類實(shí)例化對象的全部屬性信息。圖4-4展示了建造器模式的基本邏輯關(guān)系：

圖 4-4 建造器模式UML類圖

4.1.5 原型模式-Prototype

​ 原型模式的主要作用是可以利用現(xiàn)有的類通過復(fù)制（克?。┑姆绞絼?chuàng)建一個新的對象。當(dāng)示例化一個類的對象需要耗費(fèi)大量的時間和系統(tǒng)資源時，可是采用原型模式，將原始已存在的對象通過復(fù)制（克?。C(jī)制創(chuàng)建新的對象，然后根據(jù)需要，對新對象進(jìn)行修改。原型模式要求被復(fù)制的對象自身具備拷貝功能，此功能不能由外界完成。圖4-5展示了原型模式的基本邏輯：

圖4-5 原型模式UML類圖

4.2 結(jié)構(gòu)類

​ 結(jié)構(gòu)類設(shè)計(jì)模式主要解決如何通過多個小對象組合出一個大對象的問題，如使用繼承和接口實(shí)現(xiàn)將多個類組合在一起。

4.2.1 適配器模式-Adapter

​ 適配器模式的主要作用是使現(xiàn)有的多個可用接口能夠在一起為客服端提供新的接口服務(wù)。在適配器模式中，負(fù)責(zé)連接不同接口的對象成為適配器。在現(xiàn)實(shí)生活中，我們也能夠找到很多實(shí)際的案例來理解適配器的工作原理，例如常用的手機(jī)充電頭，在手機(jī)和電源插座之間，手機(jī)充電頭就扮演一個適配器的角色，它能夠同時適配220V，200V，120V等不同的電壓，最終將電轉(zhuǎn)換成手機(jī)可用的5V電壓為手機(jī)進(jìn)行充電。圖4-6展示了適配器的基本原理：

圖 4-6 適配器模式UML類圖

4.2.2 組合模式-Composite

​ 組合模式的主要作用是讓整體與局部之前具有相同的行為。例如我們需要繪制一個圖形（正方形，三角形，圓形或其他多邊形），首先需要準(zhǔn)備一張空白的紙，然后是選擇一種繪制圖案的顏色，再次是確定繪制圖案的大小，***是繪制圖案。不管是繪制正方形還是三角形，都需要按照這個步驟進(jìn)行。在軟件設(shè)計(jì)過程中，組合模式的***意義在于保證了客戶端在調(diào)用單個對象與組合對象時，在其操作流程上是保持一致的。圖4-7展示了組合模式的基本原理：

圖 4-7 組合模式UML類圖

4.2.3 代理模式-Proxy

​ 代理模式的主要作用是通過提供一個代理對象或者一個占位符來控制對實(shí)際對象的訪問行為。代理模式通常用于需要頻繁操作一些復(fù)雜對象的地方，通過使用代理模式，可以借由代理類來操作目標(biāo)對象，簡化操作流程。圖4-8展示了代理模式的基本原理：

圖 4-8 代理模式UML類圖

4.2.4 享元模式-Flywight

​ 享元模式的主要作用是通過共享來有效地支持大量細(xì)粒度的對象。例如當(dāng)需要創(chuàng)建一個類的很多對象時，可以使用享元模式，通過共享對象信息來減輕內(nèi)存負(fù)載。如果在軟件設(shè)計(jì)過程中采用享元模式，需要考慮以下三個問題：

• 應(yīng)用程序需要創(chuàng)建的對象數(shù)量是否很大？
• 對象的創(chuàng)建對內(nèi)存消耗和時間消耗是否有嚴(yán)格的要求？
• 對象的屬性是否可以分為內(nèi)在屬性和外在屬性？對象的外在屬性是否支持有客戶端定義？

圖4-9展示了享元模式的基本原理：

圖 4-9 享元模式UML類圖

4.2.5 外觀模式-Facade

​ 外觀模式的主要作用是為子系統(tǒng)中的一組接口提供一個統(tǒng)一的接口，以便客戶端更容易去使用子系統(tǒng)中的接口。簡單的理解是外觀模式為眾多復(fù)雜接口定義了一個更高級別的接口。外觀模式的目的是讓接口更容易被使用，圖4-10展示了外觀模式的基本原理：

圖 4-10 外觀模式UML類圖

4.2.6 橋接模式-Bridge

​ 橋接模式的主要用途是將抽象類與抽象類的具體實(shí)現(xiàn)相分離，以實(shí)現(xiàn)結(jié)構(gòu)上的解耦，使抽象和實(shí)現(xiàn)可以獨(dú)立的進(jìn)行變化。橋接模式的實(shí)現(xiàn)優(yōu)先遵循組合而不是繼承，當(dāng)使用橋接模式時，在一定程度上可以在客戶端中因此接口的內(nèi)部實(shí)現(xiàn)。圖4-11展示了橋接模式的基本原理：

圖 4-11 橋接模式UML類圖

4.2.7 修飾模式-Decorator

​ 修飾模式的主要作用是在運(yùn)行時動態(tài)的組合類的行為。通常，你會添加一些新的類或者新的方法來擴(kuò)展已有的代碼庫，然而，在某些情況下你需要在程序運(yùn)行時為某個對象組合新的行為，此時你可以采用修飾模式。圖4-12展示了修飾模式的基本原理：

圖 4-12 修飾模式UML類圖

4.2.8 過濾器模式-Filter

​ 過濾器模式是使用不同的標(biāo)準(zhǔn)來過濾一組對象，通過邏輯運(yùn)算以解耦的方式將對象組合起來。圖 4-13展示了過濾器模式的基本原理：

圖 4-13 過濾器模式

4.3 行為類

​ 行為類設(shè)計(jì)模式主要用于定義和描述對象之間的交互規(guī)則和職責(zé)邊界，為對象之間更好的交互提供解決方案。

4.3.1 模板方法模式-Template Method

​ 模板方法模式的主要作用是在一個方法里實(shí)現(xiàn)一個算法，可以將算法中的的一些步驟抽象為方法，并將這些方法的實(shí)現(xiàn)推遲到子類中去實(shí)現(xiàn)。例如建造一棟房子，我們需要設(shè)計(jì)圖紙，打地基，構(gòu)筑墻體，安裝門窗和內(nèi)部裝修。我們可以設(shè)計(jì)不同的房屋樣式（別墅，高樓，板房等）,不同的門窗和不同的裝修材料和風(fēng)格，但是其順序不能顛倒。在這種情況下，我們可以定義一個模板方法，規(guī)定方法的執(zhí)行順序，而將方法的實(shí)現(xiàn)推遲到子類中完成。圖4-14展示了模板方法模式的基本原理：

圖 4-14 模板方法模式UML類圖

4.3.2 解釋器模式-Mediator

​ 解釋器（中介）模式的主要設(shè)計(jì)意圖是定義一個中間對象，封裝一組對象的交互，從而降低對象的耦合度，避免了對象間的顯示引用，并可以獨(dú)立地改變對象的行為。解釋器（中介）模式可以在系統(tǒng)中的不同對象之間提供集中式的交互介質(zhì)，降低系統(tǒng)中各組件的耦合度。圖 4-15展示了解釋器（中介）模式的基本原理：

圖 4-15 解釋器（中介）模式UML類圖

4.3.3 責(zé)任鏈模式-Chain of Responsibility

​ 責(zé)任鏈模式主要作用是讓多個對象具有對同一任務(wù)（請求）的處理機(jī)會，以解除請求發(fā)送者與接收者之間的耦合度。try-catch就是一個典型的責(zé)任鏈模式的應(yīng)用案例。在try-catch語句中，可以同時存在多個catch語句塊，每個catch語句塊都是處理該特定異常的處理器。當(dāng)try語句塊中發(fā)生異常是，異常將被發(fā)送到***個catch語句塊進(jìn)行處理，如果***個語句塊無法處理它，它將會被請求轉(zhuǎn)發(fā)到鏈中的下一個catch語句塊。如果***一個catch語句塊仍然不能處理該異常，則該異常將會被向上拋出。圖4-16展示了責(zé)任鏈模式的基本原理：

圖 4-16 責(zé)任鏈模式UML類圖

4.3.4 觀察者模式-Observer

​ 觀察者模式的目的是在多個對象之間定義一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，觀察者會通知依賴它的對象，并根據(jù)新狀態(tài)做出相應(yīng)的反應(yīng)。簡單來說，如果你需要在對象狀態(tài)發(fā)生改變時及時收到通知，你可以定義一個監(jiān)聽器，對該對象的狀態(tài)進(jìn)行監(jiān)聽，此時的監(jiān)聽器即為觀察者（Observer），被監(jiān)聽對象稱為主題（Subject）。Java消息服務(wù)（JMS）即采用了觀察者設(shè)計(jì)模式（同時還使用了中介模式），允許應(yīng)用程序訂閱數(shù)據(jù)并將數(shù)據(jù)發(fā)布到其他應(yīng)用程序中。圖4-17展示了觀察者模式的基本原理：

圖 4-17 觀察者模式UML類圖

4.3.5 策略模式-Strategy

​ 策略模式的主要目的是將可互換的方法封裝在各自獨(dú)立的類中，并且讓每個方法都實(shí)現(xiàn)一個公共的操作。策略模式定義了策略的輸入與輸出，實(shí)現(xiàn)則由各個獨(dú)立的類完成。策略模式可以讓一組策略共存，代碼互不干擾，它不僅將選擇策略的邏輯從策略本身中分離出來，還幫助我們組織和簡化了代碼。一個典型的例子是Collections.sort()方法，采用Comparator作為方法參數(shù)，根據(jù)Comparator接口實(shí)現(xiàn)類的不同，對象將以不同的方式進(jìn)行排序。圖 4-18 展示了策略模式的基本原理：

圖 4-18 策略模式UML類圖

4.3.6 命令模式-Command

​ 命令模式的設(shè)計(jì)意圖是將請求封裝在對象的內(nèi)部。直接調(diào)用是執(zhí)行方法的通常做法，然而，在有些時候我們無法控制方法被執(zhí)行的時機(jī)和上下文信息。在這種情況下，可以將方法封裝到對象的內(nèi)部，通過在對象內(nèi)部存儲調(diào)用方所需要的信息，就可以讓客戶端或者服務(wù)自由決定何時調(diào)用方法。圖 4-19 展示了命令模式的基本原理：

圖 4-19 命令模式UML類圖

4.37 狀態(tài)模式-State

​ 狀態(tài)模式的設(shè)計(jì)意圖是更具對象的狀態(tài)改變其行為。如果我們必須根據(jù)對象的狀態(tài)改變對象的行為，可以在對象中定義一個狀態(tài)變量，并使用邏輯判斷語句塊（如if-else）根據(jù)狀態(tài)執(zhí)行不同的操作。圖4-20展示了狀態(tài)模式的基本原理：

圖 4-20 狀態(tài)模式UML類圖

4.3.8 訪客模式-Visitor

​ 訪客模式的設(shè)計(jì)意圖是在不改變現(xiàn)有類層次結(jié)構(gòu)的前提下，對該層次結(jié)構(gòu)進(jìn)行擴(kuò)展。例如在購物網(wǎng)站中，我們將不同的商品添加進(jìn)購物車，然后支付按鈕時，它會計(jì)算出需要支付的總金額數(shù)。我們可以在購物車類中完成金額的計(jì)算，也可以使用訪客模式，將購物應(yīng)付金額邏輯轉(zhuǎn)移到新的類中。圖 4-21展示了訪客模式的基本原理：

圖 4-21 訪客模式UML類圖

4.3.9 轉(zhuǎn)義（翻譯）模式-Interpreter

​ 轉(zhuǎn)義（翻譯）模式的設(shè)計(jì)意圖是讓你根據(jù)事先定義好的一系列組合規(guī)則，組合可執(zhí)行的對象。實(shí)現(xiàn)轉(zhuǎn)義（翻譯）模式的一個基本步驟如下：

• 創(chuàng)建執(zhí)行解釋工作的上下文引擎
• 根據(jù)不同的表達(dá)式實(shí)現(xiàn)類，實(shí)現(xiàn)上下文中的解釋工作
• 創(chuàng)建一個客戶端，客戶端從用戶那里獲取輸入，并決定使用哪一種表達(dá)式來輸出轉(zhuǎn)義后的內(nèi)容

圖4-22展示了轉(zhuǎn)義（翻譯）模式的基本原理：

圖 4-22 轉(zhuǎn)義（翻譯）模式UML類圖

4.3.10 迭代器模式-Iterator

​ 迭代器模式為迭代一組對象提供了一個標(biāo)準(zhǔn)的方法。迭代器模式被廣泛的應(yīng)用于Java Collection框架中，Iterator接口提供了遍歷集合元素的方法。迭代器模式不僅僅是遍歷集合，我們還可以根據(jù)不同的要求提供不同類型的迭代器。迭代器模式通過集合隱藏內(nèi)部的遍歷細(xì)節(jié)，客戶端只需要使用對應(yīng)的迭代方法即可完成元素的遍歷操作。圖4-23 展示了迭代器的基本原理：

圖 4-23 迭代器模式UML類圖

4.3.11 備忘錄模式-Memento

​ 備忘錄模式的設(shè)計(jì)意圖是為對象的狀態(tài)提供存儲和恢復(fù)功能。備忘錄模式由兩個對象來實(shí)現(xiàn)-Originator和Caretaker。Originator需要具有保存和恢復(fù)對象狀態(tài)的能力，它使用內(nèi)部類來保存對象的狀態(tài)。內(nèi)部內(nèi)則稱為備忘錄，因?yàn)樗菍ο笏接械模虼送獠款惒荒苤苯釉L問它。圖4-24展示了備忘錄模式的基本原理：

圖 4-24 備忘錄模式UML類圖

小節(jié)

​ 在本篇文章中，說明了模式是指解決某個特定領(lǐng)域問題，實(shí)現(xiàn)既定目標(biāo)的方法或思想；設(shè)計(jì)模式是一種通用的、可重復(fù)使用的用于解決既定范圍內(nèi)普遍發(fā)生的重復(fù)性問題的軟件設(shè)計(jì)方法。同時，對Java中常見的設(shè)計(jì)模式進(jìn)行了分類，設(shè)計(jì)模式分為建造、結(jié)構(gòu)和行為三種類型，并對每種類型的設(shè)計(jì)模式的基本概念和原理進(jìn)行了介紹，在后續(xù)的章節(jié)中，將詳細(xì)的介紹每種設(shè)計(jì)模式的原理、使用方式和適用范圍，并給出相應(yīng)的實(shí)戰(zhàn)源碼。