設計模式是很多前人留下的經驗總結，這些模式都是很典型的也是很有代表意義的。因此掌握好設計模式是提高個人技術能力的捷徑。設計模式要全部掌握，必須進行不斷的總結和實現，傻蛋最近總結了一下23種（+簡單工廠）設計模式的索引，以方便大家明白各種模式都有什么作用，在遇到問題的時候能夠迅速地找到解決方案，同時加以使用，以便能夠更快的掌握。

1.Simple Factory（簡單工廠）：:提供一個創建對象實例的集合，而無須關心其具體實現。被創建的類型可以是接口、抽象類也可以是具體類。 簡單工廠的本質：選擇實現。 2.Facade（外觀）：為子系統中的一組接口提供了一個統一一致的界面，該模式定了一個高層接口，這個接口使得這一子系統更加容易使用。 外觀模式的本質：封裝交互，簡化應用。 3.Adapter（適配器）：將一個類的接口裝換成客戶希望的另外一個接口。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。 適配器模式的本質：轉換匹配，服用功能。 4.Singleton（單例）：保證一個類僅有一個實例，并提供一個訪問它的全局訪問點。 單例模式的本質:控制實例的數目。 5.Factory Method（工廠方法）：定義一個用于創建對象的接口，讓子類來決定實例化哪一個類，該模式使一個類的實例化延遲到子類，即是讓父類在不知道具體實現的情況下，完成自身的功能調用，具體的實現延遲到子類。 工廠方法的本質：延遲到子類來選擇實現。

?

6.Abstract Factory（抽象工廠）：提供了一個創建一系列相關或者“相互依賴對象的接口”，而無需指定他們的具體類。也就是說既要創建接口的對象，同時還要約束它們之間的關系。可以類比創建主板和CPU對象，但是Intel的CPU只能插在支持Intel主板的插槽上面。在實現App的DAO的時候，通常可以使用抽象工廠結合工廠方法的方式來實現。 抽象工廠的本質：選擇產品簇的實現。 7.Builder（構建者）：將一個復雜的對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。類比文件的導出問題，每種文件都有文件的頭、文件Body、和文件尾和最終的導出，所以對于不同的文件的構建方式相同但是表現方式不同。 構建者模式的本質:分離整體構建算法和部件的構造。 8.Prototype（原型）：用原型實例創建對象的種類，并通過copy這些原型創建新的對象。會用到Clone方法。類比處理訂單（大訂單分成若干個小的訂單）問題，訂單有企業訂單和個人訂單，其實其操作過程是相似的。 原型模式的本質：克隆生成對象。 9.Mediator（中介）： 用一個中介對象來封裝一系列的對象交互。中介者使得各個對象不需要顯示地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。類比主板用于和各種配件之間交流，而不需要各種配件之間交流。當處理部門和員工之間關系時，此模式就很好，比如部門的解散會影響到部門中的人員，部門和人員之間實現了緊耦合，使用中介者就可以變為松耦合，部門不知道員工，員工不知道處于哪個部門。 中介模式的本質：封裝交互。 10.Proxy（代理）：為其他對象提供一種代理以控制對這個對象的訪問。如spring中的AOP。或者對于大數據量列表的加載，當需要知道某條數據的詳細信息的時候才通過Proxy來訪問真實對象。 代理模式的本質：控制對象的訪問。 11.Observer（觀察者）:定義對象之間的一種一對多的依賴關系。當目標對象發生狀態的改變時，所有的觀察者對象都會得到通知，從而自動更新。 觀察者模式的本質：觸發聯動 12.Command（命令）: 客戶端只是想要發出命令或者請求，而不關心請求的真正接收者是誰，也不關心具體的實現是如何的，而且對于同一個請求的動作可以有不同的請求內容，當然具體的處理功能也就不同。所以命令模式就是將一個請求封裝成一個對象，從而可以使你可以用不同的請求對客戶的請求進行參數化，請求可以進行排隊，同時也支持請求的“可撤銷操作”。 命令模式可以用于宏命令，就是一個大的命令中包含著一組小的命令。同時也可以處理隊列請求，就是指對命令的對象進行排隊，組成工作隊列，然后依次取出命令對象來進行執行。 命令模式的本質：封裝請求。 13.Iterator（迭代器）：提供一個方法順序的訪問一個聚合對象中的各個元素，而又不需要暴露該對象的內部表示。迭代器模式對于處理對數據庫數據的翻頁等事件是很好的，傳統的方式有二：1.每翻一頁就請求一次數據庫。2.把所有數據都加載在數據庫中。而迭代模式可以很好的實現一次訪問數據庫，就只趣比如10頁，這樣就不用每次都從數據庫中取了。既節省了時間，也節省了內存。 迭代器模式的本質：控制訪問聚合對象中的元素。 14.Composite（組合）：組合模式主要用于表示“樹-葉子”的層次結構，組合模式使得用戶對單個對象和組合對象的使用具有一致性，既組合模式通過引入一個抽象類，作為樹類別和葉子別的父類，這樣就把樹對象和葉子對象統一起來，用戶在使用的時候，始終是在操作此抽象的組件對象而不用區分其實樹對象還是葉子對象。其最關鍵的還是這個抽象類，這樣無論是對樹操作還是葉子操作都具有了一致性。 組合模式的本質：統一葉子對象和樹對象 15.Template Method（模板方法）：定義一個操作中的算法骨架，從而讓將一些方法的實現延遲到子類中，在不同的子類中，對這些方法的實現可以進行重寫。對于用有很多重復、相似的操作的業務處理，就可以用這個方法。 在Java中通常就使用 繼承的方法和回調的方式，使得父類可以訪問子類的方法，所以模板方法有兩種實現方式，繼承的方式和回調的方式，繼承的方式相對簡單，而回調的方式相對地靈活。 模板方法的本質：固定算法骨架。 16.Strategy（策略）：定義一系列的算法，并把它們一個個地封裝起來，并且使它們可以相互替換，本模式可以使算法可以獨立于使用它的客戶端的變化而變化。策略的重心不是如何來實現算法，而是如何組織、調用這些算法，從而讓程序結構更加靈活，具有更好的擴展性。 策略的本質是：分離算法、選擇實現。 17.State（狀態模式）：允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它的類。即對于同一個業務，在各個狀態下的處理基本上都是不同的，因此把每個狀態所對應的功能處理封裝在一個獨立的類中，這樣在選擇不同處理的時候，其實就是在選在不同的狀態處理類。 狀態模式的本質：根據狀態來分離和選擇行為。 18.Memento（備忘錄模式）：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，并在該對象之外保存這個狀態。這樣以后就可以將該對象恢復到原先保存的狀態。備忘錄的典型應用是 離線存儲。 備忘錄模式的本質：保存和恢復內部狀態。 19.Flyweigth（享元模式）：運用共享技術有效地支持大量細粒度的對象。典型的應用就是對權限的控制。 享元模式的本質：運用共享技術有效地支持大量細粒度的對象。 20.Interpreter（解釋器模式）：當讀取xml時，xml文件發生了改變，相應的解釋程序也會發生改變。用來解決這個問題的方法是解釋器模式。相當于定義一個語言，同時定義一個它的語法表示，并且定義一個解釋器，這個解釋器就是用該表示來解釋語言中的句子。 解釋器模式的本質：分離實現、解釋執行。 21.Decorator（裝飾模式）：動態地給一個對象添加一些額外得職責。對增加功能來說，裝飾模式比生成子類更為靈活。裝飾模式也能用來實現AOP。 裝飾模式的本質：動態組合。 22.Chain of Responsibility（責任鏈）：使多個對象都有機會來處理請求，從而避免請求的發送者和接收者的耦合關系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，知道有個一對象處理它為止。責任鏈模式主要是用來處理。責任鏈就是用來處理 客戶端發來一個請求，有多個對象都有機會來處理這個請求，但是客戶端不知道究竟是誰來處理這個對象。這樣就實現了請求者和接收者解耦，這樣就可以動態地切換和組合接收者了。 責任鏈的本質：分離職責，自由組合。 23.Bridge（橋接模式）：將抽象部分和它的實現部分分離，使它們都可以獨立的變化。所謂橋接就是在抽象和實現之間搭橋，讓它們能夠連接起來，可以相互通訊。抽象一定是要實現的，所以就需要搭一個橋，讓抽象部門通過這個橋就可以調用到實現部分的功能，這樣就實現了抽象和實現的徹底分離，抽象部分和實現部分可以獨立的變化。 橋接模式的本質：分離抽象和實現。 24.Visitor（訪問者）：作用于某個對象中各個元素的操作，它使在不改變各個元素的類得前提下定義作用于這些元素的操作。 訪問者模式的本質：預留通路，回調實現。

?

總結

以上是生活随笔為你收集整理的23种设计模式的索引的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。