設計模式c++學習筆記之一(strategy策略模式)
設計模式c++學習筆記之二（proxy**模式）
設計模式c++學習筆記之三（singleton單例模式）
設計模式c++學習筆記之四（multition多例模式）
設計模式c++學習筆記之五（factory method工廠方法模式）
設計模式c++學習筆記之六（facade門面模式）
設計模式c++學習筆記之七（abstractfactory抽象工廠模式）
設計模式c++學習筆記之八（adapter介面卡模式）
設計模式c++學習筆記之九（template method模板方法模式）
設計模式c++學習筆記之十（builder建造者模式）
設計模式c++學習筆記之十一（bridge橋梁模式）
設計模式c++學習筆記之十二（command命令模式）
設計模式c++學習筆記之十三（decorator裝飾模式）
設計模式c++學習筆記之十四（iterator迭代器模式）
設計模式c++學習筆記之十五（composite組合模式）
設計模式c++學習筆記之十六（observer觀察者模式）
設計模式c++學習筆記之十七（chain of responsibility責任鏈模式）
設計模式c++學習筆記之十八（visitor訪問者模式）
設計模式c++學習筆記之十九（state狀態模式）
個人理解：
1、策略模式：context包含抽象策略類，例項化context時傳入不同策略實現類，則在介面呼叫時，呼叫不同策略類。多型
2、**模式：看著這個**模式，真讓人頭暈，簡直和策略模式沒區別，如果非要和策略模式比的話，唯一的區別就是context類也繼承了抽象策略類，**模式的**也必須實現抽象介面的類的函式，因此，**清楚的知道被**的人是幹什麼的。所以**人可以成為中介。
3、單例模式：在系統中只允許產生這個類的乙個例項。
4、多例模式：有限個單例，多類單例
5、工廠方法模式：定義乙個建立產品物件的工廠介面，將實際建立工作推遲到子類當中。工廠方法屬於建立型模式。(簡單工程模式可以理解為工廠方法模式的特例)
6、門面模式：為子系統中的一組介面提供乙個一致的介面，將複雜邏輯封裝起來，對外只有乙個簡單的介面，感覺和上述幾種模式還有很大區別，就功能上來看，好像只是為了把複雜邏輯封裝，而提供給客戶乙個統一的介面。
7、抽象工廠模式：工廠模式適用於產品種類不多的情況，而抽象工廠模式就是解決這一類問題而產生的，抽象工廠模式適用於橫向和縱向都能分類的元素，主要解決產品族問題
8、介面卡模式：adapter模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。物件適配：繼承系統內部介面類並宣告要適配的介面類物件；類適配：繼承系統內部介面類和要適配的介面類。
9、模板方法模式：定義乙個操作中的演算法的骨架，而將一些步驟延遲到子類中，這種模式的邏輯基本是固定的，而把不同的實現封裝在子類中，並且基類中的共有呼叫介面不允許被覆蓋，模板方法屬於行為型模式
10、builder建造者模式：建造者模式和抽象工廠非常類似。建造者更重視產品建造時的邏輯順序，而抽象工廠更重視生產出不同型號的產品，抽象工廠不關心順序
11、bridge橋接模式：屬於結構型模式，這個模式意在提供乙個橋梁類，包含目標抽象類，例項化抽象橋梁類，在使用中例項化的橋梁類傳入不同的目標例項類物件，則表現出不同的行為。
12、command命令模式：將乙個請求封裝為乙個物件，而這個物件內部通過操作類實現了一定的功能，請求和操作均是有抽象基類，命令物件是由命令執行者來操作的。
13、decorator裝飾模式：屬於行為型模式，裝飾類必然有乙個父類指標作為成員變數，這個父類指標可以指向被裝飾類，也可以指向裝飾類。這樣多個裝飾類一起就可以組成複雜的裝飾結構。
14、iterator迭代器模式：暫時沒看出來有什麼好的，可能個人工作和學習中沒有遇到類似的處理情況吧。
15、composite組合模式：組合模式有透明組合模式和安全組合模式，透明組合模式更抽象，不過容易出現邏輯問題。
看到這個組合模式，是不是有點兒眼熟，這個和裝飾模式很像，不過既然是兩種模式，那當然是有區別的，共同點：同乙個基類，組合模式中的分支可以看做裝飾模式中的裝飾類，組合模式中的葉子可以看做裝飾模式中的被裝飾類；區別：組合模式的分支可以包含多個分支或者葉子，裝飾模式中的裝飾類只能包含乙個裝飾類或者被裝飾類，裝飾類一般都是多個，而分支是一種(也可以時多種)。裝飾模式的重點在於每個裝飾類都實現了一定的功能，多個裝飾類來共同裝飾乙個被裝飾物件，組合模式使得使用者對單個物件和組合的使用具有一致性。
16、observer觀察者模式：屬於行為型模式，物件間的一種一對多的依賴關係，被觀察物件保留觀察者的指標集，當被觀察者需要通知觀察者時，遍歷觀察者集合，通知觀察者自己傳送變化，這個模式理解起來比較容易。
17、chain of responsibility責任鏈模式：顧名思義，請求的處理是乙個佇列，當前模組處理不了的時候交給下個模組，知道找到能處理該請求的模組，責任鏈模式說白了就像乙個鍊錶似的，責任處理抽象類指標代表著每個節點，指標指向責任處理實際類，這個模式也比較簡單。
18、visitor訪問者模式：屬於行為型模式，訪問者模式是由訪問者
主動發出的動作，觀察者模式是由被觀察物件發出的變化動作，這兩種模式存在的情景不一樣。訪問者模式中：a接受b的訪問，b主動的執行訪問動作，過程：a呼叫接收訪問方法，引數為b的引用或者指標，a的方法內部在通過以引數傳遞進來的b物件，呼叫b的訪問動作函式(訪問要幹的事情)，並把自己當做引數傳遞到b物件的函式中，可能有點兒繞口，我自己都讀了好幾遍。
19、state狀態模式：屬於行為型模式，每個狀態封裝到乙個模組，上下文負責維護當前狀態，感覺似乎用的比較少。
為了更好的供大家理解，給出乙個uml類圖關係
【箭泛化關係】：是一種繼承關係，表示一般與特殊的關係，【箭頭指向】：帶三角箭頭的實線，箭頭指向父類
【實現關係】：是一種類與介面的關係，表示類是介面所有特徵和行為的實現，【箭頭指向】：帶三角箭頭的虛線，箭頭指向介面
【關聯關係】：是一種擁有的關係，它使乙個類知道另乙個類的屬性和方法，【箭頭及指向】：帶普通箭頭的實心線，指向被擁有者
【聚合關係】：是整體與部分的關係，且部分可以離開整體而單獨存在，聚合關係是關聯關係的一種，是強的關聯關係，【箭頭及指向】：帶空心菱形的實心線，菱形指向整體
【組合關係】：是整體與部分的關係，但部分不能離開整體而單獨存在，組合關係是關聯關係的一種，是比聚合關係還要強的關係，【箭頭及指向】：帶實心菱形的實線，菱形指向整體
【依賴關係】：是一種使用的關係，即乙個類的實現需要另乙個類的協助，【箭頭及指向】：帶箭頭的虛線，指向被使用者
設計模式理解
常有人調侃設計模式 語言留下的坑，就要設計模式來填。設計模式就是描述在各種不同情況下，要怎麼解決問題的一種方案。對於一些專案，我們不可能做到一次開發終身使用，而是隨著需求的不斷增多，我們需要對程式進行不斷地修改，以此來適應新的需求，通過好的設計模式，可以使我們程式松耦合，減少彼此之間的依賴，從而使其...
理解設計模式
title 理解設計模式 url tags 1.單一職責 單一功能原則 規定每個類都應該有乙個單一的功能，並且該功能能夠由這個類完全封裝起來。所有他 這個類 的服務都應該嚴密的和該功能平行 功能平行，即沒有任何依賴 保持乙個類專注於單一功能點上的乙個重要的原因是，他使得類更加健壯。簡單通俗來說 乙個...
設計模式 裝飾模式（理解）
看了 大話設計模式 pdf版的裝飾模式和其他部落格上的一些講解，第一遍很難get到講解的點在哪。經國深思，記錄下深思的結果。裝飾模式，其實就是用遞迴的方式實現了面向切面 介面 程式設計。面向切面程式設計，可以從spring框架 aop 那裡學到，模式用途，面向切面程式設計，在不用修改遠 的基礎上，新...