這篇文章主要介紹“Java設(shè)計(jì)模式的基本概念和分類”，在日常操作中，相信很多人在Java設(shè)計(jì)模式的基本概念和分類問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Java設(shè)計(jì)模式的基本概念和分類”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

成都創(chuàng)新互聯(lián)專注于石龍企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè),成都做商城網(wǎng)站。石龍網(wǎng)站建設(shè)公司,為石龍等地區(qū)提供建站服務(wù)。全流程按需求定制開發(fā)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

1 模式的基本概念

模式是指解決某個(gè)特定領(lǐng)域問題，實(shí)現(xiàn)既定目標(biāo)的方法或思想。具體來說，模式是那些身處于某個(gè)行業(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í)間，從而實(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)建一個(gè)新的對象

• 結(jié)構(gòu)類設(shè)計(jì)模式：主要用于定義如何使用多個(gè)對象組合出一個(gè)或多個(gè)復(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ì)模式。現(xiàn)已知的設(shè)計(jì)模式還有100多種，如DAO模式，依賴注入模式和MVC模式等。

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

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

4.1 建造類

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

4.1.1 單例模式-Singleton

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

• 單例模式限制類的實(shí)例化，且Java虛擬機(jī)中只能存在一個(gè)該類的示例化對象

• 單例模式必須提供一個(gè)全局可用的訪問入口來獲取該類的實(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)一個(gè)超類(super class)具有多個(gè)子類(sub  class)，且需要頻繁的創(chuàng)建子類對象時(shí)，我們可以采用工廠模式。工廠模式的作用是將子類的實(shí)例化工作統(tǒng)一交由工廠類來完成，通過對輸入?yún)?shù)的判斷，工廠類自動實(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

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

圖4-3 抽象工廠模式

4.1.4 建造器模式-Builder

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

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

4.1.5 原型模式-Prototype

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

圖4-5 原型模式UML類圖

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

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

4.2.1 適配器模式-Adapter

  適配器模式的主要作用是使現(xiàn)有的多個(gè)可用接口能夠在一起為客服端提供新的接口服務(wù)。在適配器模式中，負(fù)責(zé)連接不同接口的對象成為適配器。在現(xiàn)實(shí)生活中，我們也能夠找到很多實(shí)際的案例來理解適配器的工作原理，例如常用的手機(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ì)過程中，組合模式的***意義在于保證了客戶端在調(diào)用單個(gè)對象與組合對象時(shí)，在其操作流程上是保持一致的。圖4-7展示了組合模式的基本原理：

圖 4-7 組合模式UML類圖

4.2.3 代理模式-Proxy

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

圖 4-8 代理模式UML類圖

4.2.4 享元模式-Flywight

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

• 應(yīng)用程序需要創(chuàng)建的對象數(shù)量是否很大？

• 對象的創(chuàng)建對內(nèi)存消耗和時(shí)間消耗是否有嚴(yán)格的要求？

• 對象的屬性是否可以分為內(nèi)在屬性和外在屬性？對象的外在屬性是否支持有客戶端定義？

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

圖 4-9 享元模式UML類圖

4.2.5 外觀模式-Facade

外觀模式的主要作用是為子系統(tǒng)中的一組接口提供一個(gè)統(tǒng)一的接口，以便客戶端更容易去使用子系統(tǒng)中的接口。簡單的理解是外觀模式為眾多復(fù)雜接口定義了一個(gè)更高級別的接口。外觀模式的目的是讓接口更容易被使用，圖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í)動態(tài)的組合類的行為。通常，你會添加一些新的類或者新的方法來擴(kuò)展已有的代碼庫，然而，在某些情況下你需要在程序運(yùn)行時(shí)為某個(gè)對象組合新的行為，此時(shí)你可以采用修飾模式。圖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

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

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

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

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

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

4.3.4 觀察者模式-Observer

  觀察者模式的目的是在多個(gè)對象之間定義一對多的依賴關(guān)系，當(dāng)一個(gè)對象的狀態(tài)發(fā)生改變時(shí)，觀察者會通知依賴它的對象，并根據(jù)新狀態(tài)做出相應(yīng)的反應(yīng)。簡單來說，如果你需要在對象狀態(tài)發(fā)生改變時(shí)及時(shí)收到通知，你可以定義一個(gè)監(jiān)聽器，對該對象的狀態(tài)進(jìn)行監(jiān)聽，此時(shí)的監(jiān)聽器即為觀察者（Observer），被監(jiān)聽對象稱為主題（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ú)立的類完成。策略模式可以讓一組策略共存，代碼互不干擾，它不僅將選擇策略的邏輯從策略本身中分離出來，還幫助我們組織和簡化了代碼。一個(gè)典型的例子是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í)行方法的通常做法，然而，在有些時(shí)候我們無法控制方法被執(zhí)行的時(shí)機(jī)和上下文信息。在這種情況下，可以將方法封裝到對象的內(nèi)部，通過在對象內(nèi)部存儲調(diào)用方所需要的信息，就可以讓客戶端或者服務(wù)自由決定何時(shí)調(diào)用方法。圖  4-19 展示了命令模式的基本原理：

圖 4-19 命令模式UML類圖

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

狀態(tài)模式的設(shè)計(jì)意圖是更具對象的狀態(tài)改變其行為。如果我們必須根據(jù)對象的狀態(tài)改變對象的行為，可以在對象中定義一個(gè)狀態(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)購物車，然后支付按鈕時(shí)，它會計(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)義（翻譯）模式的一個(gè)基本步驟如下：

• 創(chuàng)建執(zhí)行解釋工作的上下文引擎

• 根據(jù)不同的表達(dá)式實(shí)現(xiàn)類，實(shí)現(xiàn)上下文中的解釋工作

• 創(chuàng)建一個(gè)客戶端，客戶端從用戶那里獲取輸入，并決定使用哪一種表達(dá)式來輸出轉(zhuǎn)義后的內(nèi)容

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

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

4.3.10 迭代器模式-Iterator

 迭代器模式為迭代一組對象提供了一個(gè)標(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ù)功能。備忘錄模式由兩個(gè)對象來實(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類圖

到此，關(guān)于“Java設(shè)計(jì)模式的基本概念和分類”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！