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

[[270600]]

1 模式的基本概念

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

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

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

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

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

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

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

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

​ 建造類共包括五(5)種基本設(shè)計(jì)模式：?jiǎn)卫Ｊ?，工廠模式，抽象工廠模式，建造器模式和原型模式，如圖3-2所示：

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

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

​ 結(jié)構(gòu)類共包括八(8)種基本設(shè)計(jì)模式：適配器模式，組合模式，代理模式，享元模式，過(guò)濾器模式，橋接模式，修飾模式和外觀模式，如圖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ì)模式

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

4.1 建造類

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

4.1.1 單例模式-Singleton

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

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

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

圖4-1 單例模式類圖

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

4.1.2 工廠模式-Factory

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

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

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

圖4-2 工廠模式UML類圖

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

4.1.3 抽象工廠模式-Abstract Factory

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

圖4-3 抽象工廠模式

4.1.4 建造器模式-Builder

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

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

4.1.5 原型模式-Prototype

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

圖4-5 原型模式UML類圖

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

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

4.2.1 適配器模式-Adapter

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

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

4.2.2 組合模式-Composite

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

圖 4-7 組合模式UML類圖

4.2.3 代理模式-Proxy

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

圖 4-8 代理模式UML類圖

4.2.4 享元模式-Flywight

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

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

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

圖 4-9 享元模式UML類圖

4.2.5 外觀模式-Facade

​ 外觀模式的主要作用是為子系統(tǒng)中的一組接口提供一個(gè)統(tǒng)一的接口，以便客戶端更容易去使用子系統(tǒng)中的接口。簡(jiǎn)單的理解是外觀模式為眾多復(fù)雜接口定義了一個(gè)更高級(jí)別的接口。外觀模式的目的是讓接口更容易被使用，圖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)使用橋接模式時(shí)，在一定程度上可以在客戶端中因此接口的內(nèi)部實(shí)現(xiàn)。圖4-11展示了橋接模式的基本原理：

圖 4-11 橋接模式UML類圖

4.2.7 修飾模式-Decorator

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

圖 4-12 修飾模式UML類圖

4.2.8 過(guò)濾器模式-Filter

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

圖 4-13 過(guò)濾器模式

4.3 行為類

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

4.3.1 模板方法模式-Template Method

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

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

4.3.2 解釋器模式-Mediator

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

圖 4-15 解釋器(中介)模式UML類圖

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

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

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

4.3.4 觀察者模式-Observer

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

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

4.3.5 策略模式-Strategy

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

圖 4-18 策略模式UML類圖

4.3.6 命令模式-Command

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

圖 4-19 命令模式UML類圖

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

​ 狀態(tài)模式的設(shè)計(jì)意圖是更具對(duì)象的狀態(tài)改變其行為。如果我們必須根據(jù)對(duì)象的狀態(tài)改變對(duì)象的行為，可以在對(duì)象中定義一個(gè)狀態(tài)變量，并使用邏輯判斷語(yǔ)句塊(如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)的前提下，對(duì)該層次結(jié)構(gòu)進(jìn)行擴(kuò)展。例如在購(gòu)物網(wǎng)站中，我們將不同的商品添加進(jìn)購(gòu)物車，然后支付按鈕時(shí)，它會(huì)計(jì)算出需要支付的總金額數(shù)。我們可以在購(gòu)物車類中完成金額的計(jì)算，也可以使用訪客模式，將購(gòu)物應(yīng)付金額邏輯轉(zhuǎn)移到新的類中。圖 4-21展示了訪客模式的基本原理：

圖 4-21 訪客模式UML類圖

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

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

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

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

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

4.3.10 迭代器模式-Iterator

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

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

4.3.11 備忘錄模式-Memento

​ 備忘錄模式的設(shè)計(jì)意圖是為對(duì)象的狀態(tài)提供存儲(chǔ)和恢復(fù)功能。備忘錄模式由兩個(gè)對(duì)象來(lái)實(shí)現(xiàn)-Originator和Caretaker。Originator需要具有保存和恢復(fù)對(duì)象狀態(tài)的能力，它使用內(nèi)部類來(lái)保存對(duì)象的狀態(tài)。內(nèi)部?jī)?nèi)則稱為備忘錄，因?yàn)樗菍?duì)象私有的，因此外部類不能直接訪問(wèn)它。圖4-24展示了備忘錄模式的基本原理：

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

小節(jié)

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