前言
軟件開發越來越複雜，對軟件設計的要求也越來越高，而軟件設計和架構的入門功夫就是深入理解和掌握設計模式。因此，設計模式的重要性不言而喻。
很多朋友認識到了設計模式的重要性，也看了很多的書籍和資料，但是，常聽到這樣的抱怨:“ 設計模式的書我看了不少，覺得都看懂了，就是不知道在實際開發中怎麼運用這些設計模式”，從而認爲設計模式是"看上去很美的花拳繡腿”。
其實不然，造成這種情況的原因就在於:這些朋友對設計模式的理解不到位，自己感覺懂了，其實還差很遠，並沒有“真正”理解和掌握設計模式。
本文就針對這種情況，讓大家真正理解和掌握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種設計模式，走遍天下都不怕！！小編只能夠幫助大家到這裏了，希望大家能夠珍惜這個學習機會！！