結構型模式（Structural Pattern）關註如何將現有類或對象組織在一起形成更加強大的結構 可分為兩種： 1. 類結構型模式：關心類的組合，由多個類可以組合成一個更大的系統，在類結構型模式中一般只存在繼承關係和實現關係 2. 對象結構型模式：關心類與對象的組合，通過關聯關係使得在一個類中定 ...
結構型模式（Structural Pattern）關註如何將現有類或對象組織在一起形成更加強大的結構
可分為兩種：
- 類結構型模式：關心類的組合，由多個類可以組合成一個更大的系統，在類結構型模式中一般只存在繼承關係和實現關係
- 對象結構型模式：關心類與對象的組合，通過關聯關係使得在一個類中定義另一個類的實例對象，然後通過該對象調用其方法。更符合“合成復用原則”
1. 適配器模式（Adapter pattern）
1.1 定義
"Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces."
將一個介面轉換成客戶希望的另一個介面，適配器模式使介面不相容的那些類可以一起工作
又稱包裝器（Wrapper），既可以作為類結構型模式，也可以作為對象結構型模式。
使用前提或場景：解決兩個已有介面間不相容問題。Client面向介面編程，而該面向的介面又與第三方介面不相容，兩者又不便於修改，則可用Adapter協調工作
個人理解：不能說是"轉換"，而是協調不相容介面間工作。比如客戶端期望調用的方法傳參是一個樣子（面向介面編程，該方法可上升為目標抽象類，下述角色中有提到），而現有第三方實現的滿足業務功能的介面可用，但規定的參數格式不一樣。但兩者（目標抽象類與第三方介面）都不願或者不能修改，因此，則需要一個適配器來協調兩者工作。
1.2 模式結構
包含如下角色：
Target（目標抽象類）
客戶期望的業務介面，可以是具體類，也可以是介面。Adapter（適配器類）
適配器類可調用Adaptee介面，以對 Adaptee 和 Target 進行適配，使其協調工作。Adaptee（適配者類）
被適配的角色，定義了可工作、已存在、待適配的介面，些情況下甚至沒有源代碼。Client（客戶類）
客戶類面對目標抽象類進行編程
可細分為兩種模式：
- 類適配器模式：適配器類與適配者類是繼承關係，因為Java不支持多重繼承，因此該模式下目標抽象類只能是介面。
- 對象適配器：適配器類與適配者類是關聯關係（也可以稱為委派關係），即含有適配者類的成員變數
1.3 模式擴展
1) 預設適配器模式（Default Adapter Pattern）：當不需要實現介面提供的全部方法時，可先設計一個抽象類（預設適配器）來實現該介面，併為每個方法提供一個預設實現（通常是空實現，也稱鉤子方法[Hook Method]），那麼該抽象類的子類（具體業務類）可有選擇的只覆蓋父類中某些方法來實現需求。
interface ServiceInterface{
void M1();
void M2();
void M3();
}
abstract class AbstractServiceClass implements ServiceInterface{
public void M1(){}
public void M2(){}
public void M3(){}
}
class ConcreteServiceClass extends AbstractServiceClass{
public void M2(){
System.out.println("具體業務方法");
}
}2) 雙向適配器：適配器中同時包含對目標類和適配者類的引用。
1.4 優缺點
也是其使用場景，可以在不修改客戶、適配者、目標抽象類前提下，讓幾者相容工作。同時適配器也能很方便的替換，符合開閉原則。
2. 橋接模式（Bridge Pattern）
2.1 定義
"Decouple an abstraction from its implementation so that the two can vary independently."
將抽象部分與它的實現部分解耦，使它們都能獨立地變化
又稱柄體（Handle and Body）模式，介面（Interface）模式，屬於對象結構型模式。
使用場景：當一個類存在兩個獨立變化的維度時，為了減少因繼承結構帶來的具體類數量，可將變化的維度進行抽象化，再用關聯方式將其聯繫起來。
個人理解：如上面所講，多變化維度如果用繼承將會大大增加類的數量。比如下麵例子中的"跨平臺多格式播放器"，若將其中一個維度用繼承關係表達，再在其中定義另一個維度介面的成員變數，以此達到靈活組合的目的。
2.2 模式結構
Abstraction（抽象類）
其中一個變化維度的繼承關係結構中的抽象父類，一般來說 Implementor 介面僅提供基本操作，而 Abstraction 則可能會做更多更複雜的操作。其中定義了一個 Implementor 類型對象，並維護該對象，達成關聯關係.RefinedAbstraction（擴充抽象類）
Implementor（實現類介面）
另一變化維度所抽象出來的介面ConcreteImplementor（具體實現類）
2.3 優點
通過將另一維度抽象，並使用關聯關係，一定程度上進行瞭解耦，也 滿足了"合成復用原則"，大大減少了因靜態抽象繼承結構可能帶來的類的數量。
因為抽象，客戶端面向兩個維度抽象層編程，加上新增擴充抽象類或具體實現類均不需要修改其他任何代碼，因此很好的符合了"依賴倒轉原則"與"開閉原則"。
3. 組合模式（Composite Pattern）
3.1 定義
"Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly."
組合多個對象形成樹形結構以表示"部分——整體"的層次結構。組合模式使客戶能統一對待單個對象（即葉子對象）和組合對象（即容器對象）
又稱"部分-整體"（Part-Whole）模式，屬於對象的結構模式
使用場景：在具有整體（容器）和部分（葉子）的類層次結構中，希望能忽略兩者的差異，使客戶能一致對待它們。
個人理解：通過定義一個抽象構件類，既能代表葉子也能代表容器構件，其中聲明瞭構件的統一業務方法，該方法葉子與容器有不同的實現，但客戶面向該抽象構件編程，因此可以統一處理而無須關心兩者間差異。
3.2 模式結構
Component（抽象構件）
可以是介面或者抽象類，聲明葉子構件與容器構件共有業務方法Leaf（葉子構件）
Composite（容器構件）
在容器構件中，包含了一個集合用於儲存子結點，該子結點可以是葉子、也可以是容器對象。且額外提供了管理子結點的方法，如addLeaf(Component com)等等Client（客戶類）
註：該模式又可細分為：透明組合模式、安全組合模式
透明組合模式：即將容器類中的額外方法（如addLeaf），提到抽象構件類中，使得所有構建類都有相同的介面，客戶可透明的完全一致地對待所有對象。
缺點很大：因為葉子對象和容器對象本質上是有區別，葉子對象不可能有成員對象。因此add等方法對葉子類是沒有意義的，在運行時調用會出錯。安全組合模式（推薦）：即沒有在抽象構件類中聲明本該容器具有的方法，這是安全的。但這會造成客戶不能完全針對抽象編程（因為add等方法是定義在容器類中的，只有聲明為容器類型才能調用）無法一致使用葉子與容器構件。
4. 裝飾模式（Decorator Pattern）
4.1 定義
"Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality."
動態地給一個對象添加職責。相較於繼承，裝飾模式則提供了一種更為靈活的方式來擴展功能。
又稱"油漆工模式"、"包裝器（Wrapper）"（與適配器模式別名相同，但含義不同），是對象結構型模式。
使用場景：無須使用繼承，通過關聯機制來動態、透明的為對象增加職責。
個人理解：定義抽象構件（類或介面）聲明業務方法，具體構件與裝飾類均實現該介面。在裝飾類中定義了構件類型的成員變數，在介面方法中調用該對象的方法並添加額外實現。而對客戶來說是一直的，因為其面向抽象編程。
該模式也能達到迴圈裝飾，來添加功能。
4.2 模式結構
Component（抽象構件）
聲明瞭業務方法，客戶端面向該抽象編程ConcreteComponent（具體構件）
實現了抽象構件Decorator（抽象裝飾類）
（可選）實現抽象構件。當有多個裝飾類時，可聲明抽象裝飾類，用以定義所有裝飾類的統一行為，如維護一個抽象構件類型的引用。假如只有一個裝飾類時，則可省略ConcreteDecorator（具體裝飾類）
內部調用被裝飾對象方法，並額外增添新的功能。
註：該模式可細分為透明裝飾模式與半透明裝飾模式。
- 透明裝飾模式：即裝飾類中未額外添加public方法，客戶端可完全一致的使用具體構建類與裝飾類。
- 半透明裝飾模式：裝飾類中增添了自己的方法，意味著客戶端必須聲明為裝飾類型才可調用，因此無法一致對待。
4.3 優點
一定程度上降低了靜態繼承帶來的耦合度，符合”合成復用原則“，同時抽象層的定義也符合”開閉原則“，比如新增具體裝飾類無須修改其他代碼。
5. 外觀模式（Facade Pattern）
5.1 定義
"Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use."
為子系統的一組介面提供一個統一的入口。外觀模式定義了一個高層介面使得能更方便地使用子系統。
又稱門面模式，是對象結構型模式
使用場景：若想簡化客戶端與複雜子系統間的操作，則可引入外觀角色來為複雜子系統提供簡化的入口
個人理解：如上所述，客戶端只需與外觀角色交互，而由外觀角色來整合調用子系統中的複雜介面
5.2 模式結構
SubSystem（子系統角色）
每個子系統都可由客戶端直接調用，也可以被外觀角色調用。子系統並不知道外觀角色的存在，對子系統而言，外觀角色僅僅是另一個客戶端而已Facade（外觀角色）
它將從客戶端發來的請求委派到相應子系統
5.3 優點
如同使用情景一樣，使用外觀模式可為客戶端提供很大方便，將客戶端與子系統的內部複雜性分隔開，只需與外觀角色交互即可。降低了客戶與子系統耦合度，符合"迪米特法則"。
6.享元模式
TODO
7. 代理模式（Proxy Pattern / Surrogate Pattern）
7.1 定義
"Provide a surrogate or placeholder for another object to control access to it."
為某一對象提供一個代理，由代理對象來控制對原對象的引用
屬於對象結構型模式
使用場景及個人理解：為現有對象的使用提供額外的控制，而無須修改現有類與客戶調用，對客戶端而言是透明的，無須關心具體實現，只需面向介面使用即可。Java中官方自帶有對動態代理的支持。
和“裝飾模式”的不同：(1)代理中的引用是對真實主題角色的引用，而裝飾模式中是對抽象主題角色的引用。(2)裝飾模式的被裝飾對象是由客戶傳入的，想額外增加修飾功能。而代理模式是內部創建被代理對象，且完全控制其行為。
7.2 模式結構
Subject（抽象主題角色）
定義了業務方法，是真實主題與代理主題的共同介面Proxy（代理主題角色）
內部包含對真實主題角色的引用，可完全控制真實主題的使用邏輯RealSubject（真實主題角色）
7.3 擴展
常見應用：
- 遠程代理：遠程代理可以將網路細節隱藏起來，使客戶端不必考慮網路的存在。比如Java的RMI(Remote Method Invocation，遠程方法調用)，客戶對象在客戶端運行，想伺服器端運行的遠程對象發起請求。
- 虛擬代理：一種時間換空間的記憶體節省技術，將占用大量記憶體或處理複雜的對象推遲到使用它時才創建。比如Hibernate的懶載入
Java中的動態代理，以及優缺點：
TODO：一個鏈接
