**（proxy）模式：【中介】
介面卡（adapter）模式：【轉換器】
1.定義：將乙個類的介面轉換成客戶希望的另外乙個介面，使得原本由於介面不相容而不能一起工作的那些類能一起工作。
2.優點：復用了現存的類、將目標類和適配者類解耦，解決了目標類和適配者類介面不一致的問題。
3.缺點：更換介面卡的實現過程比較複雜。
4.結構：
目標（target）介面：當前系統業務所期待的介面，它可以是抽象類或介面。
適配者（adaptee）類：它是被訪問和適配的現存元件庫中的元件介面。
介面卡（adapter）類：它是乙個【轉換器】，通過繼承或引用適配者的物件，把適配者介面轉換成目標介面，讓客戶按目標介面的格式訪問適配者。
5.應用場景：
以前開發的系統存在滿足新系統功能需求的類，但其介面同新系統的介面不一致。
使用第三方提供的元件，但元件介面定義和自己要求的介面定義不同。
橋接（bridge）模式：【兩個可變維度】
1.定義：將抽象與實現分離，使它們可以獨立變化。它是用組合關係代替繼承關係來實現的，從而降低了抽象和實現這兩個可變維度的耦合度。
2.優點：由於抽象與實現分離，所以擴充套件能力強；其實現細節對客戶透明。
3.缺點：由於聚合關係建立在抽象層，要求開發者針對抽象化進行設計與程式設計，這增加了系統的理解與設計難度。
4.結構：
抽象化（abstraction）角色：定義抽象類，幷包含乙個對實現化物件的引用。
擴充套件抽象化（refined abstraction）角色：是抽象化角色的子類，實現父類中的業務方法，並通過組合關係呼叫實現化角色中的業務方法。
實現化（implementor）角色：定義實現化角色的介面，供擴充套件抽象化角色呼叫。
具體實現化（concrete implementor）角色：給出實現化角色介面的具體實現。
5.應用場景：
當乙個類存在兩個獨立變化的維度，且這兩個維度都需要進行擴充套件時。
當乙個系統不希望使用繼承或因為多層次繼承導致系統類的個數急劇增加時。
當乙個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性時。
裝飾（decorator）模式：【增加物件額外的功能】
1.定義：不改變現有物件結構的情況下，動態增加其額外功能。
2.優點：比採用繼承方式更加靈活。擴充套件多樣化。
3.缺點：子類多，使程式複雜。
4.結構：
抽象構件（component）角色：定義乙個抽象介面以規範準備接收附加責任的物件。
具體構件（concrete component）角色：實現抽象構件，通過裝飾角色為其新增一些職責。
抽象裝飾（decorator）角色：繼承抽象構件，幷包含具體構件的例項，可以通過其子類擴充套件具體構件的功能。
具體裝飾（concretedecorator）角色：實現抽象裝飾的相關方法，並給具體構件物件新增附加的責任。
5.應用場景：
當需要給乙個現有類新增附加職責，而又不能採用生成子類的方法進行擴充時。
當物件的功能要求可以動態地新增，也可以再動態地撤銷時。
外觀（facade）模式：【多個子系統】
1.定義：為多個複雜的子系統提供乙個一致的介面，使這些子系統更加容易被訪問。
2.優點：
a.降低了子系統與客戶端之間的耦合度.
b.對客戶遮蔽了子系統元件，減少了客戶處理的物件數目，並使得子系統使用起來更加容易。
c.降低了大型軟體系統中的編譯依賴性，簡化了系統在不同平台之間的移植過程，因為編譯乙個子系統不會影響其他的子系統，也不會影響外觀物件。
3.缺點：
a.不能很好地限制客戶使用子系統類。
b.增加新的子系統可能需要修改外觀類或客戶端的源**，違背了「開閉原則」。
4.結構：
外觀（facade）角色：為多個子系統對外提供乙個共同的介面。
子系統（sub system）角色：實現系統的部分功能，客戶可以通過外觀角色訪問它。
客戶（client）角色：通過乙個外觀角色訪問各個子系統的功能。
5.應用模式：
對分層結構系統構建時，使用外觀模式定義子系統中每層的入口點可以簡化子系統之間的依賴關係。
當乙個複雜系統的子系統很多時，外觀模式可以為系統設計乙個簡單的介面供外界訪問。
當客戶端與多個子系統之間存在很大的聯絡時，引入外觀模式可將它們分離，從而提高子系統的獨立性和可移植性。
1.定義：運用共享技術來有效地支援大量細粒度物件的復用，提高系統的效能。享元模式的本質是分離與共享 ：分離變與不變，並且共享不變。
2.優點：相同物件只要儲存乙份，這降低了系統中物件的數量，從而降低了系統中細粒度物件給記憶體帶來的壓力。
3.缺點：
a.為了使物件可以共享【內部狀態，可共享部分】，需要將一些【外部狀態，不能共享】的狀態外部化，這將增加程式的複雜性。
b.讀取享元模式的外部狀態會使得執行時間稍微變長。
4.結構：
抽象享元角色（flyweight）:是所有的具體享元類的基類，為具體享元規範需要實現的公共介面，非享元的外部狀態以引數的形式通過方法傳入。
具體享元（concrete flyweight）角色：實現抽象享元角色中所規定的介面。
非享元（unsharable flyweight)角色：是不可以共享的外部狀態，它以引數的形式注入具體享元的相關方法中。
享元工廠（flyweight factory）角色：負責建立和管理享元角色。當客戶物件請求乙個享元物件時，享元工廠檢查系統中是否存在符合要求的享元物件，如果存在則提供給客戶；如果不存在的話，則建立乙個新的享元物件。
5.應用場景：
系統中存在大量相同或相似的物件，這些物件耗費大量的記憶體資源。
大部分的物件可以按照內部狀態進行分組，且可將不同部分外部化，這樣每乙個組只需儲存乙個內部狀態。
由於享元模式需要額外維護乙個儲存享元的資料結構，所以應當在有足夠多的享元例項時才值得使用享元模式。
string常量池、資料庫連線池、緩衝池等等都是享元模式的應用，所以說【享元模式是池技術的重要實現方式】。
組合（composite）模式：【有層級的結構】
1.定義：將物件組合成樹狀層次結構，使使用者對單個物件和組合物件具有一致的訪問性。
2.優點：
a.組合模式使得客戶端**可以一致地處理單個物件和組合物件，無須關心自己處理的是單個物件，還是組合物件，這簡化了客戶端**；
b.更容易在組合體內加入新的物件，客戶端不會因為加入了新的物件而更改源**，滿足「開閉原則」；
3.缺點：
設計較複雜，客戶端需要花更多時間理清類之間的層次關係；
不容易限制容器中的構件；
不容易用繼承的方法來增加構件的新功能；
4.結構：
抽象構件（component）角色：它的主要作用是為樹葉構件和樹枝構件宣告公共介面，並實現它們的預設行為。
樹葉構件（leaf）角色：是組合中的葉節點物件，它沒有子節點，用於實現抽象構件角色中 宣告的公共介面。
樹枝構件（composite）角色：是組合中的分支節點物件，它有子節點。它實現了抽象構件角色中宣告的介面，它的主要作用是儲存和管理子部件，通常包含 add()、remove()、getchild() 等方法。
組合模式分為透明式的組合模式和安全式的組合模式：
(1) 透明方式：在該方式中，由於抽象構件宣告了所有子類中的全部方法，所以客戶端無須區別樹葉物件和樹枝物件，對客戶端來說是透明的。
但其缺點是：樹葉構件本來沒有 add()、remove() 及 getchild() 方法，卻要實現它們（空實現或拋異常）
(2) 安全方式：在該方式中，將管理子構件的方法移到樹枝構件中，抽象構件和樹葉構件沒有對子物件的管理方法，這樣就避免了上一種方式的安全性問題。
但由於葉子和分支有不同的介面，客戶端在呼叫時要知道樹葉物件和樹枝物件的存在，所以失去了透明性。
5.應用場景：
在需要表示乙個物件整體與部分的層次結構的場合。
要求對使用者隱藏組合物件與單個物件的不同，使用者可以用統一的介面使用組合結構中的所有物件的場合。
設計模式 結構型模式
介面卡模式 adapter pattern 橋接模式 bridge pattern 過濾器模式 filter criteria pattern 組合模式 composite pattern 裝飾器模式 decorator pattern 外觀模式 facade pattern 享元模式 flywei...
設計模式 結構型模式
外觀模式 為子系統中的一組介面提供乙個一致的介面，外觀模式定義了乙個高層介面，這個介面使得這一系統更加容易使用。介面卡模式 將乙個類的介面轉換成客戶希望的另外乙個介面。它使得原本由於介面不相容而不能一起工作的那些類一起工作。橋接模式 將抽象部分與它的實現部分分離，使它們可以獨立地變化。組合模式 將物...
《設計模式》結構型模式
上篇博文寫了建立型模式中的 工廠家族 這次來介紹一下結構型模式。主要從各個模式的含義，優缺點，適用場合及結構圖來了解結構型模式。結構型模式包括有 種模式，介面卡模式，外觀模式，模式，橋接模式，享元模式，組合模式，裝飾模式。每個模式各有優缺，孰優孰劣，請看下文。定義 將乙個類的介面轉換成客戶希望的另外...