9.模板模式
模板模式：封裝了一個算法步驟，並允許子類爲一個或多個步驟方法提供實現。模板模式可以使子類在不改變算法結構的情況下，重新定義算法中的某些步驟。
templateMethod():模板步驟方法，定義了模板的執行的邏輯順序。
AbsOperation():抽象方法，是由子類必須實現的。
concreteOp():具體方法，是由超類來實現的。
hook():可選方法，是指超類裏實現了默認的方法，但子類裏可以選擇是否重寫。
好萊塢原則：
原則：“不要給我們打電話，我們會給你打電話(don‘t call us, we‘ll call you)”
意義：層次之間無需知道調用底層的細節，即增加一個調度的中間層來實現各個層次的解耦。
模板模式與策略模式的差異：
1.模板模式封裝的是步驟，而策略模式主要是方法和功能的體系化不強調順序。
2.模板模式是通過繼承的方式來實現，而策略模式是通過組合的方式來實現的。
10.迭代器模式
迭代器模式：提供一種方法順序訪問一個聚合對象中的各個對象。
迭代器模式由以下角色組成：
迭代器角色（Iterator）: 負責定義訪問和遍歷元素的接口。
具體迭代器角色（Concrete Iterator）：實現迭代器接口，並要記錄遍歷中的當前位置。
容器角色(Aggregate): 負責提供創建具體迭代器角色的接口。
具體容器角色（ConcreteAggregate）：實現創建具體迭代器角色的接口， 這個具體迭代器角色與該容器的結構相關。
類圖：
單一責任原則：
一個類應該只有一個引起變化的原因。
11.組合模式
組合模式:將對象聚合成樹形結構來表現"整體/部分"的層次結構。
組合模式能讓客戶以一致的方式來處理個別對象以及對象組合。
看下組合模式的組成。
1) 抽象構件角色Component：它爲組合中的對象聲明接口，也可以爲共有接口實現缺省行爲。
2) 樹葉構件角色Leaf：在組合中表示葉節點對象——沒有子節點，實現抽象構件角色聲明的接口。
3) 樹枝構件角色Composite：在組合中表示分支節點對象——有子節點，實現抽象構件角色聲明的接口；存儲子部件。
優缺點:
組合模式有以下優點：
1) 使客戶端調用簡單，客戶端可以一致的使用組合結構或其中單個對象，用戶就不必關心自己處理的是單個對象還是整個組合結構，這就簡化了客戶端代碼。
2) 更容易在組合體內加入對象部件. 客戶端不必因爲加入了新的對象部件而更改代碼。這一點符合開閉原則的要求，對系統的二次開發和功能擴展很有利！
當然組合模式也少不了缺點：組合模式不容易限制組合中的構件。
12.狀態模式
策略模式、狀態模式和模版模式的各自的意義：
1.狀態模式和策略模式的差異：
狀態模式和策略模式的維度是一樣的；但他們的意義是不一樣的。狀態模式的狀態的改變是目的的一部分；而策略模式的功能改變只是初始化可變化的行爲，初始化行爲之後功能基本不變。所以策略模式一般情況下可以作爲狀態模式的基礎。
2.狀態模式和模版模式的差異：
模版模式的動作是封裝好的，每個動作是整體的一部分；而狀態模式的動作都是一個整體。如果模板模式把每個動作拆開來封裝成一個整體，就形成了狀態模式。
13.代理模式
代理模式：爲一個對象提供一個替身，以控制對這個對象訪問。被代理的對象可以是遠程對象、創建開銷大的對象或需要安全控制的對象。代理模式有很多變體，都是爲了控制與管理對象訪問。
類圖：
常見的代理模式
虛擬代理:虛擬代理爲創建開銷大的對象提供代理服務。真正的對象在創建中時，由虛擬代理來扮演替身。
動態代理:運行時動態的創建代理類對象，並將方法調用轉發到指定類。
保護代理:控制和管理代理可以調用的遠程方法
其他的代理:防火牆代理、緩存代理、智能引用代理、同步代理、寫入時複製代理。
代理模式和裝飾者模式的差異
裝飾者模式是添加新功能，而代理模式目的是對目標對象訪問的控制和管理。
14.複合模式
MVC複合模式
Model-View-Controller ：模型-視圖-控制器，複合模式。
MVC是由數個設計模式結合起來的模式。
例子：MP3播放器。
M，Model模型：
模型持有所有的數據、狀態和程序邏輯。
模型沒有注意到視圖和控制器，雖然它提供了操縱和檢索狀態的接口，併發送狀態改變通知給觀察者。
V，View 視圖：
視圖用來呈現模型。
視圖通常直接從模型中取得它需要顯示的狀態與數據。
C，Controller 控制器：
控制器取得用戶的輸入並解讀其對模型的意思。
控制器把控制邏輯從視圖中分離，讓模型和視圖之間解耦。通過保持控制器和視圖之間的鬆耦合，設計就更有彈性而且容易擴展。
MVC中的設計模式
模型利用觀察者模式讓控制器和視圖可以隨最新的狀態改變而更新。
模型對視圖和控制器一無所知，它們之間是完全解耦的，模型只知道有一些觀察者它需要通知。模型還提供一些接口，供視圖和控制器獲得並設置狀態。
視圖和控制器實現了策略模式。控制器是視圖的行爲，如果你希望有不同的行爲，可以直接換一個控制器。
視圖內部使用組合模式來管理窗口、按鈕以及其他顯示組件。
15.橋接模式
橋接模式:將實現與抽象放在兩個不同的層次中，使兩個層次可以獨立改變
1．橋接模式使用“對象間的組合關係”解耦了抽象和實現之間固有的綁定關係，使得抽象和實現可以沿着各自的維度來變化。
2．所謂抽象和實現沿着各自維度的變化，即“子類化”它們，得到各個子類之後，便可以任意它們，從而獲得不同路上的不同對象。
3．橋接模式有時候類似於多繼承方案，但是多繼承方案往往違背了類的單一職責原則（即一個類只有一個變化的原因），複用性比較差。橋接模式是比多繼承方案更好的解決方法。
4．橋接模式的應用一般在“兩個非常強的變化維度”，有時候即使有兩個變化的維度，但是某個方向的變化維度並不劇烈——換言之兩個變化不會導致縱橫交錯的結果，並不一定要使用橋接模式。
適用性：
在以下的情況下應當使用橋樑模式：
1．如果一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的聯繫。
2．設計要求實現化角色的任何改變不應當影響客戶端，或者說實現化角色的改變對客戶端是完全透明的。
3．一個構件有多於一個的抽象化角色和實現化角色，系統需要它們之間進行動態耦合。
4．雖然在系統中使用繼承是沒有問題的，但是由於抽象化角色和具體化角色需要獨立變化，設計要求需要獨立管理這兩者。
總結：
橋接模式是一個非常有用的模式，也非常複雜，它很好的符合了開放-封閉原則和優先使用對象，而不是繼承這兩個面向對象原則。
橋接模式與裝飾的區別:
裝飾模式:
這兩個模式在一定程度上都是爲了減少子類的數目，避免出現複雜的繼承關係。但是它們解決的方法卻各有不同，裝飾模式把子類中比基類中多出來的部分放到單獨的類裏面，以適應新功能增加的需要，當我們把描述新功能的類封裝到基類的對象裏面時，就得到了所需要的子類對象，這些描述新功能的類通過組合可以實現很多的功能組合 .
橋接模式：
橋接模式則把原來的基類的實現化細節抽象出來，在構造到一個實現化的結構中，然後再把原來的基類改造成一個抽象化的等級結構，這樣就可以實現系統在多個維度上的獨立變化 。
16.生成器模式
建造者（Builder）角色：給出一個抽象接口，以規範產品對象的各個組成成分的建造。一般而言，此接口獨立於應用程序的商業邏輯。模式中直接創建產品對象的是具體建造者（ConcreteBuilder）角色。具體建造者類必須實現這個接口所要求的方法：一個是建造方法，另一個是結果返還方法。
具體建造者（Concrete Builder）角色：擔任這個角色的是於應用程序緊密相關的類，它們在應用程序調用下創建產品實例。這個角色主要完成的任務包括：
- 實現Builder角色提供的接口，一步一步完成創建產品實例的過程。
- 在建造過程完成後，提供產品的實例。
指導者（Director）角色：擔任這個角色的類調用具體建造者角色以創建產品對象。導演者並沒有產品類的具體知識，真正擁有產品類的具體知識的是具體建造者對象。
產品（Product）角色：產品便是建造中的複雜對象。
指導者角色是於客戶端打交道的角色。導演者角色將客戶端創建產品的請求劃分爲對各個零件的建造請求，再將這些請求委派給具體建造者角色。具體建造者角色是做具體建造工作的，但卻不爲客戶端所知。
優點: