開端-Java設計模式導讀

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

​本篇文章時Java設計模式系列技術文章的開篇，作為導讀文章，將快速地對設計模式的基本概念、模式分類和適用范圍進行解讀。在后續的章節中，將對每一種類別的設計模式進行詳細的講解，講解的內容包括每種設計模式的基本原理、適用范圍和實戰案例剖析三個部分。

1 模式的基本概念

​ 模式是指解決某個特定領域問題，實現既定目標的方法或思想。具體來說，模式是那些身處于某個行業的從業人員根據實際的工作經驗總結出的，具有通用性的且被行業公認的解決問題的方法或流程。模式并非只在軟件工程中被應用，其在日常的生產活動中被廣泛地使用，如制造業，餐飲業，建筑設計、醫療衛生、教育培訓以及軟件工程等都有模式的身影。

2 什么是設計模式？

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

3 Java設計模式的分類

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

• 建造類設計模式：主要用于定義和約束如何創建一個新的對象
• 結構類設計模式：主要用于定義如何使用多個對象組合出一個或多個復合對象
• 行為類設計模式：主要用于定義和描述對象之間的交互規則和限定對象的職責邊界線

圖3-1 設計模式分類

3.1 建造類設計模式

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

圖3-2 建造類設計模式

3.2 結構類設計模式

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

圖3-3 結構類設計模式

3.3 行為類設計模式

​ 行為類共包括十一（11）種基本設計模式：模板方法模式，解釋器模式，責任鏈模式，觀察者模式，戰略模式，命令模式，狀態模式，訪客模式，轉義模式，迭代器模式和備忘錄模式，如圖3-4所示：

圖3-4 行為類設計模式

​ 設計模式不僅僅只有上述描述的這三大類，除此之外還有許多的設計模式。現已知的設計模式還有100多種，如DAO模式，依賴注入模式和MVC模式等。

4 快速理解設計模式

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

4.1 建造類

​ 建造類設計模式提供了對創建對象的基本定義和約束條件，以尋求***的實例化Java對象解決方案。

4.1.1 單例模式-Singleton

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

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

單例模式的Java類的內部結構如圖4-1所示：

圖4-1 單例模式類圖

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

4.1.2 工廠模式-Factory

​ 在Java程序設計過程中，當一個超類(super class)具有多個子類(sub class)，且需要頻繁的創建子類對象時，我們可以采用工廠模式。工廠模式的作用是將子類的實例化工作統一交由工廠類來完成，通過對輸入參數的判斷，工廠類自動實例化具體的子類。實現工廠模式需要滿足三個條件：

• 超類（super class）：超類是一個抽象類
• 子類（sub class）: 子類需繼承超類
• 工廠類（factory class）:工廠類根據輸入參數實例化子類

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

圖4-2 工廠模式UML類圖

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

4.1.3 抽象工廠模式-Abstract Factory

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

圖4-3 抽象工廠模式

4.1.4 建造器模式-Builder

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

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

4.1.5 原型模式-Prototype

​ 原型模式的主要作用是可以利用現有的類通過復制（克隆）的方式創建一個新的對象。當示例化一個類的對象需要耗費大量的時間和系統資源時，可是采用原型模式，將原始已存在的對象通過復制（克隆）機制創建新的對象，然后根據需要，對新對象進行修改。原型模式要求被復制的對象自身具備拷貝功能，此功能不能由外界完成。圖4-5展示了原型模式的基本邏輯：

圖4-5 原型模式UML類圖

4.2 結構類

​ 結構類設計模式主要解決如何通過多個小對象組合出一個大對象的問題，如使用繼承和接口實現將多個類組合在一起。

4.2.1 適配器模式-Adapter

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

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

4.2.2 組合模式-Composite

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

圖 4-7 組合模式UML類圖

4.2.3 代理模式-Proxy

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

圖 4-8 代理模式UML類圖

4.2.4 享元模式-Flywight

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

• 應用程序需要創建的對象數量是否很大？
• 對象的創建對內存消耗和時間消耗是否有嚴格的要求？
• 對象的屬性是否可以分為內在屬性和外在屬性？對象的外在屬性是否支持有客戶端定義？

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

圖 4-9 享元模式UML類圖

4.2.5 外觀模式-Facade

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

圖 4-10 外觀模式UML類圖

4.2.6 橋接模式-Bridge

​ 橋接模式的主要用途是將抽象類與抽象類的具體實現相分離，以實現結構上的解耦，使抽象和實現可以獨立的進行變化。橋接模式的實現優先遵循組合而不是繼承，當使用橋接模式時，在一定程度上可以在客戶端中因此接口的內部實現。圖4-11展示了橋接模式的基本原理：

圖 4-11 橋接模式UML類圖

4.2.7 修飾模式-Decorator

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

圖 4-12 修飾模式UML類圖

4.2.8 過濾器模式-Filter

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

圖 4-13 過濾器模式

4.3 行為類

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

4.3.1 模板方法模式-Template Method

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

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

4.3.2 解釋器模式-Mediator

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

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

4.3.3 責任鏈模式-Chain of Responsibility

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

圖 4-16 責任鏈模式UML類圖

4.3.4 觀察者模式-Observer

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

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

4.3.5 策略模式-Strategy

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

圖 4-18 策略模式UML類圖

4.3.6 命令模式-Command

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

圖 4-19 命令模式UML類圖

4.37 狀態模式-State

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

圖 4-20 狀態模式UML類圖

4.3.8 訪客模式-Visitor

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

圖 4-21 訪客模式UML類圖

4.3.9 轉義（翻譯）模式-Interpreter

​ 轉義（翻譯）模式的設計意圖是讓你根據事先定義好的一系列組合規則，組合可執行的對象。實現轉義（翻譯）模式的一個基本步驟如下：

• 創建執行解釋工作的上下文引擎
• 根據不同的表達式實現類，實現上下文中的解釋工作
• 創建一個客戶端，客戶端從用戶那里獲取輸入，并決定使用哪一種表達式來輸出轉義后的內容

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

圖 4-22 轉義（翻譯）模式UML類圖

4.3.10 迭代器模式-Iterator

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

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

4.3.11 備忘錄模式-Memento

​ 備忘錄模式的設計意圖是為對象的狀態提供存儲和恢復功能。備忘錄模式由兩個對象來實現-Originator和Caretaker。Originator需要具有保存和恢復對象狀態的能力，它使用內部類來保存對象的狀態。內部內則稱為備忘錄，因為它是對象私有的，因此外部類不能直接訪問它。圖4-24展示了備忘錄模式的基本原理：

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

小節

​ 在本篇文章中，說明了模式是指解決某個特定領域問題，實現既定目標的方法或思想；設計模式是一種通用的、可重復使用的用于解決既定范圍內普遍發生的重復性問題的軟件設計方法。同時，對Java中常見的設計模式進行了分類，設計模式分為建造、結構和行為三種類型，并對每種類型的設計模式的基本概念和原理進行了介紹，在后續的章節中，將詳細的介紹每種設計模式的原理、使用方式和適用范圍，并給出相應的實戰源碼。