設計模式 —— 結構型模式

結構型模式（Structural Pattern）關注如何將現有類或對象組織在一起形成更加強大的結構
可分為兩種：

1. 類結構型模式：關心類的組合，由多個類可以組合成一個更大的系統，在類結構型模式中一般只存在繼承關系和實現關系
2. 對象結構型模式：關心類與對象的組合，通過關聯關系使得在一個類中定義另一個類的實例對象，然后通過該對象調用其方法。更符合“合成復用原則”

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 模式結構

示例代碼參考

包含如下角色：

1. Target（目標抽象類）
   客戶期望的業務接口，可以是具體類，也可以是接口。

2. Adapter（適配器類）
   適配器類可調用Adaptee接口，以對 Adaptee 和 Target 進行適配，使其協調工作。

3. Adaptee（適配者類）
   被適配的角色，定義了可工作、已存在、待適配的接口，些情況下甚至沒有源代碼。

4. Client（客戶類）
   客戶類面對目標抽象類進行編程

可細分為兩種模式：

1. 類適配器模式：適配器類與適配者類是繼承關系，因為Java不支持多重繼承，因此該模式下目標抽象類只能是接口。
2. 對象適配器：適配器類與適配者類是關聯關系（也可以稱為委派關系），即含有適配者類的成員變量

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 模式結構

1. Abstraction（抽象類）
   其中一個變化維度的繼承關系結構中的抽象父類，一般來說 Implementor 接口僅提供基本操作，而 Abstraction 則可能會做更多更復雜的操作。其中定義了一個 Implementor 類型對象，並維護該對象，達成關聯關系.

2. RefinedAbstraction（擴充抽象類）

3. Implementor（實現類接口）
   另一變化維度所抽象出來的接口

4. ConcreteImplementor（具體實現類）

2.3 優點

1. 通過將另一維度抽象，並使用關聯關系，一定程度上進行了解耦，也 滿足了"合成復用原則"，大大減少了因靜態抽象繼承結構可能帶來的類的數量。

2. 因為抽象，客戶端面向兩個維度抽象層編程，加上新增擴充抽象類或具體實現類均不需要修改其他任何代碼，因此很好的符合了"依賴倒轉原則"與"開閉原則"。

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 模式結構

1. Component（抽象構件）
   可以是接口或者抽象類，聲明葉子構件與容器構件共有業務方法

2. Leaf（葉子構件）

3. Composite（容器構件）
   在容器構件中，包含了一個集合用於儲存子結點，該子結點可以是葉子、也可以是容器對象。且額外提供了管理子結點的方法，如addLeaf(Component com)等等

4. 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 模式結構

1. Component（抽象構件）
   聲明了業務方法，客戶端面向該抽象編程

2. ConcreteComponent（具體構件）
   實現了抽象構件

3. Decorator（抽象裝飾類）
   （可選）實現抽象構件。當有多個裝飾類時，可聲明抽象裝飾類，用以定義所有裝飾類的統一行為，如維護一個抽象構件類型的引用。假如只有一個裝飾類時，則可省略

4. 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 模式結構

1. SubSystem（子系統角色）
   每個子系統都可由客戶端直接調用，也可以被外觀角色調用。子系統並不知道外觀角色的存在，對子系統而言，外觀角色僅僅是另一個客戶端而已

2. 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 模式結構

1. Subject（抽象主題角色）
   定義了業務方法，是真實主題與代理主題的共同接口

2. Proxy（代理主題角色）
   內部包含對真實主題角色的引用，可完全控制真實主題的使用邏輯

3. RealSubject（真實主題角色）

7.3 擴展

常見應用：

1. 遠程代理：遠程代理可以將網絡細節隱藏起來，使客戶端不必考慮網絡的存在。比如Java的RMI(Remote Method Invocation，遠程方法調用)，客戶對象在客戶端運行，想服務器端運行的遠程對象發起請求。
2. 虛擬代理：一種時間換空間的內存節省技術，將占用大量內存或處理復雜的對象推遲到使用它時才創建。比如Hibernate的懶加載

Java中的動態代理，以及優缺點：

TODO：一個鏈接