今天上午結束了對大話設計模式的重讀，因無實際應用經驗所以仍然‘照本宣科’稍微整理陳述一下剩餘幾個設計模式的內容，算是重讀的印跡吧！
備忘錄模式：對象的狀態需要記錄以備後用時使用。備忘錄記錄發起人的內部狀態、管理者管理對備忘錄的使用，這樣“把要保存的細節給封裝在了備忘錄中，哪一天更改保存的細節也不影響客戶端了”。
組合模式：對象之間是部分-整體的層次關係時應用。“將對象組合成樹形結構以表示’部分-整體‘的層次結構。組合模式使得用戶對單個對象和組合對象的使用具有一致性。”
迭代器模式：通過一”外部查看者“對對象的內部聚集成員進行遍歷訪問。“迭代器模式就是分離了集合對象的遍歷行爲，抽象出一個迭代類來負責，這樣既可以做到不暴露集合的內部結構，又讓外部代碼透明地訪問集合內部的數據。”
單例模式：使類只有一個實例化對象，並提供一個訪問它的全局訪問點的模式。“因爲單例類封裝它的唯一實例，這樣它可以嚴格地控制客戶怎樣訪問它以及何時訪問它。簡單的說就是對唯一實例的受控訪問。”
橋接模式：”將抽象與它的實現分離，使它們都可以獨立變化。“---》“實現系統可能有多角度分類，每一種分類都有可能，那麼就把這種多角度分離出來讓它們獨立變化，減少它們之間的耦合。”
命令模式：把請求者與執行動作的實體用命令分離開來的模式。定義：“將一個請求封裝爲一個對象，從而使你可以用不同的請求對客戶進行參數化；對請求排隊或記錄請求，以及支持可撤銷的操作。”
職責鏈模式：“使多個對象都有機會處理請求，從而避免請求的發送者與接受者之間的耦合關係。將這些對象連成一條鏈，並沿着這條鏈處理，直到有一個對象處理它爲止。”
中介者模式：避免了兩個對象間的直接交互，而是通過中介者實現它們之間的交互。“優點是減少了對象間的耦合、使關注的對象從對象本身的行爲轉移到它們之間的交互上來，也就是站在一個更宏觀的角度去看待系統；缺點是中介者控制的集中化，於是就把交互複雜性變爲了中介者的複雜性。”
享元模式：當系統需要實例化很多對象，而這些對象又有不少很相似的元素時使用。“享元模式可以避免大量非常相似類的開銷。”
解釋器模式：“給定一個語言，定義它的文法的一種表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。”“使用瞭解釋器模式，就意味着可以很容易地改變和拓展文法，因爲該模式使用類來表示文法規則，你可以使用繼承來改變或拓展文法。也比較容易實現文法，因爲定義抽象語法樹中各個節點的類的實現大體類似，這些類都易於直接編寫。”
訪問者模式：“表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素類的前提下定義作用於這些元素的新操作。”它適用於對象結構穩定、但附加於其上的操作靈活多變的情況。“它把數據結構和作用於結構之上的操作間的耦合解脫開，使得操作集合可以相對自由的演化。”
訪問者模式：“表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素類的前提下定義作用於這些元素的新操作。”它適用於對象結構穩定、但附加於其上的操作靈活多變的情況。“它把數據結構和作用於結構之上的操作間的耦合解脫開，使得操作集合可以相對自由的演化。”
