前言

軟體開發越來越復雜，對軟體設計的要求也越來越高，而軟體設計和架構的入門功夫就是深入理解和掌握設計模式，因此，設計模式的重要性不言而喻，

很多朋友認識到了設計模式的重要性，也看了很多的書籍和資料，但是，常聽到這樣的抱怨:“ 設計模式的書我看了不少，覺得都看懂了，就是不知道在實際開發中怎么運用這些設計模式”，從而認為設計模式是"看上去很美的花拳繡腿”，

其實不然，造成這種情況的原因就在于:這些朋友對設計模式的理解不到位，自己感覺懂了，其實還差很遠，并沒有“真正”理解和掌握設計模式，

本文就針對這種情況，讓大家真正理解和掌握23種設計模式，并且能夠靈活運用，希望大家能夠喜歡！！！

目錄

主要內容

第1章設計模式基礎， 什么是模式？從字面上理解，模，就是模型、模板的意思:式，就是方式、方法的意思，綜合起來，所謂模式就是:可以作為模型或模板的方式或方法，再簡單點說就是可以用來作為樣板的方式或方法，類似于大家所熟悉的范例，

按照上面的理解，設計模式指的就是設計方面的模板，也即設計方面的方式或方法，

設計模式:是指在軟體開發中，經過驗證的，用于解決在特定環境下、重復出現的、特定問題的解決方案，

第2章簡單工廠，簡單工廠不是一個標準的設計模式，但是它實在是太常用了，簡單而又神奇，所以需要好好掌握它，就當是學習設計模式的熱身運動吧，為了保持一致性，我們盡量按照學習其他模式的步驟來進行學習，

第3章外觀模式，外觀模式有如下優點，

• 松散耦合：外觀模式松散了客戶端與子系統的耦合關系，讓子系統內部的模塊能更容易擴展和維護，
• 簡單易用：外觀模式讓子系統更加易用，客戶端不再需要了解子系統內部的實作，也不需要跟眾多子系統內部的模塊進行互動，只需要跟外觀互動就可以了，相當于外觀類為外部客戶端使用子系統提供了一站式服務，
• 更好地劃分訪問的層次：通過合理使用Facade,可以幫助我們更好地劃分訪問的層次，有些方法是對系統外的，有些方法是系統內部使用的，把需要暴露給外部的功能集中到外觀中，這樣既方便客戶端使用，也很好地隱藏了內部的細節，

第4章配接器模式(Adapter)，配接器模式有如下優點，

• 更好的復用性：如果功能是已經有了的，只是介面不兼容，那么通過配接器模式就可以讓這些功能得到更好的復用，
• 更好的可擴展性：在實作配接器功能的時候，可以呼叫自己開發的功能，從而自然地擴展系統的功能，

第5章單例模式(Singleton)

1.單例模式的功能

單例模式是用來保證這個類在運行期間只會被創建一一個類實體，另外，單例模式還提供了一個全域唯一訪 問這個類實體的訪問點，就是getInstance 方法，不管采用懶漢式還是餓漢式的實作方式，這個全域訪問點是一一樣的，

對于單例模式而言，不管采用何種實作方式，它都是只關心類實體的創建問題，并不關心具體的業務功能，

2.單例模式的范圍

也就是在多大范圍內是單例呢?

觀察上面的實作可以知道，目前Java里面實作的單例是一個虛擬機的范圍，因為裝載類的功能是虛擬機的，所以一個虛擬機在通過自己的ClassLoader裝載餓漢式實作單例類的時候就會創建一個類的實體，

第6章方法模式(Factory Method)

工廠方法模式的功能

工廠方法模式的主要功能是讓父類在不知道具體實作的情況下，完成自身的功能呼叫:而具體的實作延遲到子類來實作，

這樣在設計的時候，不用去考慮具體的實作，需要某個物件，把它通過工廠方法返,回就好了，在使用這些物件實作功能的時候還是通過介面來操作，這類似于IoC/DI的思想，這個在后面將給大家稍詳細點介紹，

第7章抽象工廠模式(Abstract Factory)

抽象工廠模式的功能

抽象工廠的功能是為一系列相關物件或相互依賴的物件創建一-個介面，一 *定要注意，這個介面內的方法不是任意堆砌的，而是一系列相關或相互依賴的方法，比如上面例子中的CPU和主板，都是為了組裝一臺電腦的相關物件，

從某種意義上看，抽象工廠其實是一個產品系列，或者是產品簇，上面例子中的抽象工廠就可以看成是電腦簇，每個不同的裝機方案，代表- -種具體的電腦系列，

第8章生成器模式(Builder)

生成器模式的主要功能是構建復雜的產品，而且是細化的、分步驟的構建產品，也就是生成器模式重在一步一步解決構造復雜物件的問題，如果僅僅這么認識生成器模式的功能是不夠的，

再直白點說，生成器模式的重心在于分離構建演算法和具體的構造實作，從而使得構建演算法可以重用，具體的構造實作可以很方便地擴展和切換，從而可以靈活地組合來構造出不同的產品物件，

第9章原型模式(Prototype)

原型模式的功能實際上包含兩個方面:

• 一個是通過克隆來創建新的物件實體;
• 另一個是為克隆出來的新的物件實體復制原型實體屬性的值，

原型模式要實作的主要功能就是:通過克隆來創建新的物件實體，一般來講，新創建出來的實體的資料是和原型實體一樣的，但是具體如何實作克隆，需要由程式自行實作，原型模式并沒有統-的要求和實作演算法，

第10章中介者模式(Mediator)

中介者的功能非常簡單，就是封裝物件之間的互動，如果一個物件的操作會引起其他相關物件的變化，或者是某個操作需要引起其他物件的后續或連帶操作，而這個物件又不希望自己來處理這些關系，那么就可以找中介者，把所有的麻煩扔給它，只在需要的時候通知中介者，其他的就讓中介者去處理就可以了，

反過來，其他的物件在操作的時候，可能會引起這個物件的變化，也可以這么做，

最后物件之間就完全分離了，誰都不直接跟其他物件互動，那么相互的關系全部被集中到中介者物件里面了，所有的物件就只是跟中介者物件進行通信，相互之間不再有聯系，

把所有物件之間的互動都封裝在中介者當中，無形中還可以得到另外一個好處，就是能夠集中地控制這些物件的互動關系，這樣當有變化的時候，修改起來就很方便，

第11章代理模式(Proxy)

代理模式是通過創建一個代理物件，用這個代理物件去代表真實的物件，客戶端得到這個代理物件后，對客戶端并沒有什么影響，就跟得到了真實物件一樣來使用，

當客戶端操作這個代理物件的時候，實際上功能最侄訓是會由真實的物件來完成，只不過是通過代理操作的，也就是客戶端操作代理，代理操作真正的物件，

正是因為有代理物件夾在客戶端和被代理的真實物件中間，相當于-一個中轉，那么在中轉的時候就有很多花招可以玩，比如，判斷一下權限，如果沒有足夠的權限那就不給你中轉了，

第12章觀察者模式(Observer)

按照模式的定義，目標和觀察者之間是典型的一對多的關系，

但是要注意，如果觀察者只有一一個，也是可以的，這樣就變相實作了目標和觀察者之間一-對--的關系，這也使得在處理-一個物件的狀態變化會影響到另一個物件的時候，也可以考慮使用觀察者模式，

同樣地，一個觀察者也可以觀察多個目標，如果觀察者為多個目標定義的通知更新方法都是update方法的話，這會帶來麻煩，因為需要接收多個目標的通知，如果是一一個update的方法，那就需要在方法內部區分，到底這個更新的通知來自于哪一個目標，不同的目標有不同的后續操作，

一般情況下，觀察者應該為不同的觀察者目標定義不同的回呼方法，這樣實作最簡單，不需要在update方法內部進行區分，

第13章命令模式(Command)

1. 命令模式的關鍵

命令模式的關鍵之處就是把請求封裝成為物件，也就是命 令物件，并定義了統一的執行操作的介面，這個命令物件可以被存盤、轉發、記錄、處理、撤銷等，整個命令模式都是圍繞這個物件在進行，

2.命令模式的組裝和呼叫

在命令模式中經常會有一個命令的組裝者，用它來維護命令的“虛”實作和真實實作之間的關系，如果是超級智能的命令，也就是說命令物件自己完全實作好了，不需要接收者，那就是命令模式的退化，不需要接收者，自然也不需要組裝者了，

而真正的用戶就是具體化請求的內容，然后提交請求進行觸發就可以了，真正的用戶會通過Invoker來觸發命令，

在實際開發程序中，Client 和Invoker可以融合在一起，由客戶在使用命令模式的時候，先進行命令物件和接收者的組裝，組裝完成后，就可以呼叫命令執行請求，

第14章迭代器模式(terator)

迭代器模式的功能主要在于提供對聚合物件的迭代訪問，迭代器就圍繞著這個“訪問”做文章，延伸出很多的功能來，比如:以不同的方式遍歷聚合物件，比如向前、向后等，

■對同一個聚合同時進行多個遍歷，

■以不同的遍歷策略來遍歷聚合，比如是否需要過濾等，

多型迭代，含義是:為不同的聚合結構提供統的迭代介面，也就是說通過一個迭代介面可以訪問不同的聚合結構，這就叫做多型迭代，上面的示例就 已經實作了多型迭代，事實上，標準的迭代模式實作基本上都是支持多型迭代的，

第15章組合模式(Composite)

組合模式的目的是:讓客戶端不再區分操作的是組合物件還是葉子物件，而是以一個統-一的方式來操作，

實作這個目標的關鍵之處，是設計一個抽象的組件類，讓它可以代表組合物件和葉子物件，這樣一來，客戶端就不用區分到底操作的是組合物件還是葉子物件了，只需要把它們全部當作組件物件進行統一-的操作就可以 了，

第16章模板方法模式(Template Method)

模板方法模式的功能在于固定演算法骨架，而讓具體演算法實作可擴展，

這在實際應用中非常廣泛，尤其是在設計框架級功能的時候非常有用，框架定義好了演算法的步驟，在合適的點讓開發人員進行擴展，實作具體的演算法，比如在DAO實作中設計通用的增刪改查功能，這個在后面會給大家示例，

模板方法模式還額外提供了-一個好處，就是可以控制子類的擴展，因為在父類中定義好了演算法的步驟，只是在某幾個固定的點才會呼叫到被子類實作的方法，因此也就只允許在這幾個點來擴展功能，這些可以被子類覆寫以擴展功能的方法通常被稱為“鉤子”方法，在后面也會給大家示例，

第17章策略模式(Strategy)

策略模式的功能是把具體的演算法實作從具體的業務處理中獨立出來，把它們實作成為單獨的演算法類，從而形成一系列的演算法，并讓這些演算法可以相互替換，

策略模式的重心不是如何來實作演算法，而是如何組織、呼叫這些演算法，從而讓程式結構更靈活，具有更好的維護性和擴展性，

第18章狀態模式(State)

所謂物件的狀態，通常指的就是物件實體的屬性的值:而行為指的就是物件的功能，再具體點說，行為大多可以對應到方法上，

狀態模式的功能就是分離狀態的行為，通過維護狀態的變化，來呼叫不同狀態對應的不同功能，

也就是說，狀態和行為是相關聯的，它們的關系可以描述為:狀態決定行為，

由于狀態是在運行期被改變的，因此行為也會在運行期根據狀態的改變而改變，看起來，同一一個物件，在不同的運行時刻，行為是不樣的，就像是類被修改了一樣，

第19章備忘錄模式(Memento)

備忘錄模式的功能，首先是在不破壞封裝性的前提下，捕獲一個物件的內部狀態，

這里要注意兩點，一個是不破壞封裝性，也就是物件不能暴露它不應該暴露的細節;另外一個是捕獲的是物件的內部狀態，而且通常還是運行期間某個時刻物件的內部狀態，

為什么要捕獲這個物件的內部狀態呢?捕獲這個內部狀態有什么用呢?

第20章享元模式(Flyweight)

享元模式設計的重點就在于分離變與不變，把一個物件的狀態分成內部狀態和外部狀態，內部狀態是不變的，外部狀態是可變的，然后通過共享不變的部分，達到減少物件數量并節約記憶體的目的，在享元物件需要的時候，可以從外部傳入外部狀態給共享的物件，共享物件會在功能處理的時候，使用自己內部的狀態和這些外部的狀態，

事實上，分離變與不變是軟體設計上最基本的方式之一一，比如預留介面，為什么在這個地方要預留介面，-一個常見的原因就是這里存在變化，可能在今后需要擴展或者是改變已有的實作，因此預留介面作為“可插入性的保證”，

第21章解釋器模式(Interpreter)

解釋器模式使用解釋器物件來表示和處理相應的語法規則，一般一 個解釋 器處理一條語法規則，理論上來說，只要能用解釋器物件把符合語法的運算式表示出來，而且能夠構成抽象的語法樹，那都可以使用解釋器模式來處理，

第22章裝飾模式(Decorator)

裝飾模式能夠實作動態地為物件添加功能，是從一個物件外部來給物件增加功能，相當于是改變了物件的外觀，當裝飾過后，從外部使用系統的角度看，就不再是使用原始的那個物件了，而是使用被- - 系列的裝飾器裝飾過后的物件，

這樣就能夠靈活地改變-一個對 象的功能，只要動態組合的裝飾器發生了改變，那么最終所得到的物件的功能也就發生了改變，

變相地還得到了另外-一個好處，那就是裝飾器功能的復用，可以給一個物件多次增加同一個裝飾器，也可以用同一個裝飾器裝飾不同的物件，

第23章職責鏈模式(Chain of Responsibility)

職責鏈模式主要用來處理“客戶端發出一個請求，有多個物件都有機會來處理這一個請求，但是客戶端不知道究竟誰會來處理他的請求”這樣的情況，也就是需要讓請求者和接收者解耦，這樣就可以動態地切換和組合接收者了，

如果要變形使用職責鏈，就可以讓這個請求繼續傳遞，每個職責物件對這個請求進行一定的功能處理，從而形成--個處理請求的功能鏈，

第24章橋接模式(Bridge)

在橋接模式中，不太好理解的就是橋接的概念，什么是橋接?為何需要橋接?如何橋接?把這些問題搞清楚了，也就基本明白橋接的含義了，

一個一個來，先看看什么是橋接?所謂橋接，通俗點說就是在不同的東西之間搭一個橋，讓它們能夠連接起來，可以相互通訊和使用，那么在橋接模式中到底是給什么東西來搭橋呢?就是為被分離了的抽象部分和實作部分來搭橋，比如前面示例中在抽象的訊息和具體訊息發送之間搭個橋，

第25章訪問者模式(Visitor)

訪問者模式能給一系列物件透明地添加新功能，從而避免在維護期間對這一系列物件進行修改，而且還能變相實作復用訪問者所具有的功能，

由于是針對一系列物件的操作，這也導致，如果只想給一系列物件中的部分物件添加功能，就會有些麻煩;而且要始終能保證把這一系列物件都呼叫到，不管是回圈，還是遞回，總之要讓每個物件都要被訪問到，

這份【研磨23種設計模式】共有802頁，需要完整版的朋友，可以轉發此文關注小編，查看文末圖片或私信小編【技術】來獲取！！！

還有6.17G 23種設計模式視頻配合檔案來學習，希望大家能夠喜歡！！

學好23種設計模式，走遍天下都不怕！！小編只能夠幫助大家到這里了，希望大家能夠珍惜這個學習機會！！有想要深度學習獲取的朋友，請查看下方圖片，掃描添加即可~~~