调侃《Head First设计模式》之总结篇
? ? ? ? ?在之前的設計模式博客中，主要根據《Head First設計模式》談了10個設計模式，今天來做下總結，好好梳理提煉x下精華，而且今天準備把GOF經典大作《設計模式》中的23個設計模式都總結一遍。（以下內容參考了程杰的《大話設計模式》）
? ? ? 在GOF的大作中，把23個設計模式做了分類：建造型，結構型，行為型。
? ? ?建造型的設計模式有：抽象工廠，建造者，工廠方法，原型。
? ? ?1.抽象工廠，它用于提供一個創建一系列或相關依賴對象的接口，而不需要明確指明類。
? ? ?
? ? ? ?圖中A、B代表不同的產品種類，1、2表示同種產品的不同分支，AbstractFactory是抽象工廠，它不關心實際生產出的具體產品，它只知道要生產一個包含A、B兩種產品的一個系列產品，由它的子類，具體的工廠去決定生產的具體產品。
? ? ? 2. 建造者模式：將一個復雜對象的構建和表示分離，使得同樣的建造過程可以創建不同的表示。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ?Build指明建造的過程，該過程會在Director被順序執行。而在ConcreteBuilder中指明具體的表示（即實現了建造過程的方法），一般用于同類建造過程穩定的、內部表示容易改變的產品。該表表示只要定義一個新的ConcreteBuilder就可以了。
? ? ?3.工廠方法：定義一個創建對象的接口，讓子類決定實例化哪一個類。
? ? ?
? ? ?工廠方法將具體產品的創建延遲到子類，實現了創建和使用的解耦。
? ? 4.原型模式：用原型實例指定創建對象的種類，并且通過這些原型創建新的對象。
? ? ? ?
? ? ??
? ? 5.單例模式：保證一個類只有一個實例，并提供一個訪問它的全局訪問點。
? ? ? ? ?
? ? 結構型有適配器，橋接，組合，裝飾，外觀，享元，代理。
? ? 6.適配器模式：將一個類的接口轉化為客戶希望的另一個接口，使得原來接口不兼容而不能一起工作的類可以一起工作。
? ? ? ? ? ? ? ? ? ? ??
? ? ? ? 適配器和期望的類實現同一接口，同時適配器持有被需要適配的類的引用，這樣就可以完成類的接口適配器。
? ? ?7.橋接模式：使抽象部分和實現部分分離，使它們可以獨立的變化。
? ? ? ? ? ? ? ? ? ??
? ? ??
? ? ?8.組合模式：將對象組合成樹狀結構以表示“部分-整體”的層次結構，組合模式使得用戶對單個對象和組合對象的使用具有一致性。
? ? ? ? ? ? ? ? ??
? ?
? ? ?葉節點和枝節點實現共同的接口，但是實現方法的方法不同，枝節點可以持有枝節點或者葉節點的引用，而葉節點不能?？蛻舳藢⑷~節點和枝節點一視同仁，方便遍歷，省去了冗長的判斷語句。
? ? 9.裝飾者模式：動態給對象添加一些額外的職責，比生成子類更加靈活。
? ??
? ? ?Decorator持有ConcreteComponent的引用并為其添加職責，由于ConcreteComponent和Decorator實現同一個接口，所以被裝飾者可以再一次被裝飾。
? ? 10.外觀模式：定義了一個高層的接口，為子系統的一組接口提供了一個一直一致的界面，使得子系統更加容易使用。
? ??
? ? ? Facade類將原來各個類的一些方法封裝成一個方法，按順序調用，使得一次調用就可以完成原本需要多次調用的任務。
? ? ? 11.享元模式：運用共享技術有效的支持大粒度的對象。
? ? ?
? ? ?當有大量類存在很多相似地方的時候可以用享元模式，可以大幅度減少實例化的類的對象，而對象間不同的部分，可以用其他對象來表示為外部狀態。
? ?12.代理模式：為其他對象提供代理以控制對這個對象的訪問。
? ??
? ? 由于被代理類和代理類都實現了共同接口，所以只要是使用到被代理類的地方都可以用代理來代替。
? ??
? ?行為型模式：觀察者、模板方法、命令、狀態、職責鏈、解釋器中介者、訪問者、策略、迭代器。
? ?
? ?13.觀察者模式：定義對象間一種一對多的依賴關系，當一個對象的狀態發生變化時，所以依賴它的對象收到通知并自動更新。
? ? ?
? ? ? 只要實現了Observer接口的對象都可以被觀察者觀察，觀察者不在意被觀察的對象類型，所以實現了觀察者和被觀察者的解耦。每當觀察者狀態發生變化就自動調用被觀察者的更新方法。
? ? ? 14.模板方法：定義一個算法骨架，而將一些步驟延遲到子類中，使得子類可以不改變一個算法的結構即可重新定義該算法的某些步驟。
? ? ??
? ? ? 模板方法一般在TemplateMethod方法中定義了調用幾個抽象方法PrimitiveOperation的調用順序，而PrimitiveOperation的實現延遲到子類，這樣可以根據子類的需要實現不同的執行行為，但是總的算法骨架沒有改變。這樣在節省重復代碼的情況下確保了子類實現的靈活性。常用于創建各種框架。
? ? ? 15 命令模式：將一個請求封裝成一個對象，從而使你可用不同的請求對客戶進行參數化。也可以對請求進行排隊或者記錄請求日志以及支持撤銷操作。
? ? ??
? ? ? Receiver只在意接收到的對象是否實現了Command接口，命令類將請求封裝在execute方法中，Receiver只要在需要的地方調用命令的execute方法即可,Receiver甚至不知道調用的命令是做什么的，實現了調用者和命令的解耦。
? ? 16 狀態模式：允許一個對象在內部狀態改變時改變它的行為，讓對象看起來似乎修改了它的類。
? ? ?
? ? ?一般將狀態封裝為獨立的類，并將動作委托到當前狀態對象，而Cotext狀態的切換，是在狀態類中完成的。實現了Cotext和狀態類的解耦，讓狀態種類發生變化時系統修改起來很方便，可避免大量的判斷語句。
? ? 17 職責鏈模式：使多個對象都有機會處理請求，從而避免了請求的發送者和接受者之間的耦合關系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它為止。
? ??
? ? 各個處理對象通過SetSuccessor設置下一個處理對象，當自己無法處理時就將請求交給下一個對象，于是形成職責鏈，從而實現了請求和處理者的解耦，可避免大量的判斷語句，也增加了職責鏈的靈活性（可動態修改）。
? ? ? ?
? ? 18 解釋器模式：給定一個語言，定義它的文法的一種表示，并定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。
? ? ?
? ? ??
? ? 19 中介者模式：用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地互相引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。
? ??
? ? ?Mediator是各個Colleague的中介者，各個Colleague的交互都要通過中介者完成，實現了各個Colleague的解耦。
? ?20 訪問者模式：表示一個作用于某對象結構中的各個元素的操作。它使你可以在不改變個 元素的類的前提下定義作用于這些元素的新操作。
? ?
? ? ?
? ? ? ? 訪問者模式將數據結構和作用于結構之上的操作之間的耦合解脫開，使得操作可以相對自由地演化，適用于數據結構比較穩定，又有易于變化的算法的情形。
? ?21 策略模式：定義了一系列的算法，把它們一個個封裝起來，并且使它們可以互相替換。本模式使得算法可以獨立于它們的客戶而變化。
? ??
? ?策略模式實現了算法和算法實用類的解耦，算法之間也消除了耦合，使得算法的替換變得靈活方便。
? ?22 備忘錄模式：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，并在該對象之外保存這個狀態。這樣可以在以后將對象恢復到原先保存的狀態。
? ?
? ? Originator的狀態被保存在了Memento中，Memento由Caretaker保管，不會影響到客戶端。
? ?23 迭代器模式：提供一種方法順序訪問聚合對象中各個元素，而不需要暴露該對象的內部表示。
? ?
? ? ?迭代器Iterator將遍歷一個聚合對象的算法封裝起來。客戶端只要得到一個實現Iterator接口的類對象的迭代器，就可以用統一的方式對聚合對象進行迭代操作。
總結
以上是生活随笔為你收集整理的调侃《Head First设计模式》之总结篇的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 前端学习（2440）：axios处理文章
- 下一篇： 【HeadFirst】设计模式