結構型模式描述如何將類或對象按某種布局組成更大的結構。它分為類結構型模式和對象結構型模式，前者采用繼承機制來組織接口和類，后者釆用組合或聚合來組合對象。由於組合關系或聚合關系比繼承關系耦合度低，滿足“合成復用原則”，所以對象結構型模式比類結構型模式具有更大的靈活性。結構型模式分為以下 7 種：
- 代理（Proxy）模式：為某對象提供一種代理以控制對該對象的訪問。即客戶端通過代理間接地訪問該對象，從而限制、增強或修改該對象的一些特性。
- 適配器（Adapter）模式：將一個類的接口轉換成客戶希望的另外一個接口，使得原本由於接口不兼容而不能一起工作的那些類能一起工作。
- 橋接（Bridge）模式：將抽象與實現分離，使它們可以獨立變化。它是用組合關系代替繼承關系來實現的，從而降低了抽象和實現這兩個可變維度的耦合度。
- 裝飾（Decorator）模式：動態地給對象增加一些職責，即增加其額外的功能。
- 外觀（Facade）模式：為多個復雜的子系統提供一個一致的接口，使這些子系統更加容易被訪問。
- 享元（Flyweight）模式：運用共享技術來有效地支持大量細粒度對象的復用。
- 組合（Composite）模式：將對象組合成樹狀層次結構，使用戶對單個對象和組合對象具有一致的訪問性。
1. 代理模式
代理模式（Proxy）的定義如下：由於某些原因需要給某對象提供一個代理以控制對該對象的訪問。這時，訪問對象不適合或者不能直接引用目標對象，代理對象作為訪問對象和目標對象之間的中介。
主要角色
- 抽象主題（Subject）類：通過接口或抽象類聲明真實主題和代理對象實現的業務方法。
- 真實主題（Real Subject）類：實現了抽象主題中的具體業務，是代理對象所代表的真實對象，是最終要引用的對象。
- 代理（Proxy）類：提供了與真實主題相同的接口，其內部含有對真實主題的引用，它可以訪問、控制或擴展真實主題的功能。
應用場景
- 遠程代理，這種方式通常是為了隱藏目標對象存在於不同地址空間的事實，方便客戶端訪問。例如，用戶申請某些網盤空間時，會在用戶的文件系統中建立一個虛擬的硬盤，用戶訪問虛擬硬盤時實際訪問的是網盤空間。
- 虛擬代理，這種方式通常用於要創建的目標對象開銷很大時。例如，下載一幅很大的圖像需要很長時間，因某種計算比較復雜而短時間無法完成，這時可以先用小比例的虛擬代理替換真實的對象，消除用戶對服務器慢的感覺。
- 安全代理，這種方式通常用於控制不同種類客戶對真實對象的訪問權限。
- 智能指引，主要用於調用目標對象時，代理附加一些額外的處理功能。例如，增加計算真實對象的引用次數的功能，這樣當該對象沒有被引用時，就可以自動釋放它。
- 延遲加載，指為了提高系統的性能，延遲對目標的加載。例如，Hibernate 中就存在屬性的延遲加載和關聯表的延時加載。
2. 適配器模式
適配器模式（Adapter）的定義如下：將一個類的接口轉換成客戶希望的另外一個接口，使得原本由於接口不兼容而不能一起工作的那些類能一起工作。適配器模式分為類結構型模式和對象結構型模式兩種，前者類之間的耦合度比后者高，且要求程序員了解現有組件庫中的相關組件的內部結構，所以應用相對較少些。
主要角色
- 目標（Target）接口：當前系統業務所期待的接口，它可以是抽象類或接口。
- 適配者（Adaptee）類：它是被訪問和適配的現存組件庫中的組件接口。
- 適配器（Adapter）類：它是一個轉換器，通過繼承或引用適配者的對象，把適配者接口轉換成目標接口，讓客戶按目標接口的格式訪問適配者。
應用場景
- 以前開發的系統存在滿足新系統功能需求的類，但其接口同新系統的接口不一致。
- 使用第三方提供的組件，但組件接口定義和自己要求的接口定義不同。
3. 橋接模式
橋接（Bridge）模式的定義如下：將抽象與實現分離，使它們可以獨立變化。它是用組合關系代替繼承關系來實現，從而降低了抽象和實現這兩個可變維度的耦合度。
主要角色
- 擴展抽象化（Refined Abstraction）角色：是抽象化角色的子類，實現父類中的業務方法，並通過組合關系調用實現化角色中的業務方法。
- 實現化（Implementor）角色：定義實現化角色的接口，供擴展抽象化角色調用。
- 具體實現化（Concrete Implementor）角色：給出實現化角色接口的具體實現。
應用場景
- 當一個類存在兩個獨立變化的維度，且這兩個維度都需要進行擴展時。
- 當一個系統不希望使用繼承或因為多層次繼承導致系統類的個數急劇增加時。
- 當一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性時。
4. 裝飾模式
裝飾（Decorator）模式的定義：指在不改變現有對象結構的情況下，動態地給該對象增加一些職責（即增加其額外功能）的模式。
主要角色
- 抽象構件（Component）角色：定義一個抽象接口以規范准備接收附加責任的對象。
- 具體構件（Concrete Component）角色：實現抽象構件，通過裝飾角色為其添加一些職責。
- 抽象裝飾（Decorator）角色：繼承抽象構件，並包含具體構件的實例，可以通過其子類擴展具體構件的功能。
- 具體裝飾（ConcreteDecorator）角色：實現抽象裝飾的相關方法，並給具體構件對象添加附加的責任。
應用場景
- 當需要給一個現有類添加附加職責，而又不能采用生成子類的方法進行擴充時。
- 當需要通過對現有的一組基本功能進行排列組合而產生非常多的功能時，采用繼承關系很難實現，而采用裝飾模式卻很好實現。
- 當對象的功能要求可以動態地添加，也可以再動態地撤銷時。
5. 外觀模式
外觀（Facade）模式的定義：是一種通過為多個復雜的子系統提供一個一致的接口，而使這些子系統更加容易被訪問的模式。該模式對外有一個統一接口，外部應用程序不用關心內部子系統的具體的細節，這樣會大大降低應用程序的復雜度，提高了程序的可維護性。
主要角色
- 外觀（Facade）角色：為多個子系統對外提供一個共同的接口。
- 子系統（Sub System）角色：實現系統的部分功能，客戶可以通過外觀角色訪問它。
- 客戶（Client）角色：通過一個外觀角色訪問各個子系統的功能。
應用場景
- 對分層結構系統構建時，使用外觀模式定義子系統中每層的入口點可以簡化子系統之間的依賴關系。
- 當一個復雜系統的子系統很多時，外觀模式可以為系統設計一個簡單的接口供外界訪問。
- 當客戶端與多個子系統之間存在很大的聯系時，引入外觀模式可將它們分離，從而提高子系統的獨立性和可移植性。
6. 享元模式
享元（Flyweight）模式的定義：運用共享技術來有効地支持大量細粒度對象的復用。
主要角色
- 抽象享元角色（Flyweight）:是所有的具體享元類的基類，為具體享元規范需要實現的公共接口，非享元的外部狀態以參數的形式通過方法傳入。
- 具體享元（Concrete Flyweight）角色：實現抽象享元角色中所規定的接口。
- 非享元（Unsharable Flyweight)角色：是不可以共享的外部狀態，它以參數的形式注入具體享元的相關方法中。
- 享元工廠（Flyweight Factory）角色：負責創建和管理享元角色。當客戶對象請求一個享元對象時，享元工廠檢査系統中是否存在符合要求的享元對象，如果存在則提供給客戶；如果不存在的話，則創建一個新的享元對象。
應用場景
- 系統中存在大量相同或相似的對象，這些對象耗費大量的內存資源。
- 大部分的對象可以按照內部狀態進行分組，且可將不同部分外部化，這樣每一個組只需保存一個內部狀態。
- 由於享元模式需要額外維護一個保存享元的數據結構，所以應當在有足夠多的享元實例時才值得使用享元模式。
7. 組合模式
組合（Composite）模式的定義：有時又叫作部分-整體模式，它是一種將對象組合成樹狀的層次結構的模式，用來表示“部分-整體”的關系，使用戶對單個對象和組合對象具有一致的訪問性。
主要角色：
- 抽象構件（Component）角色：它的主要作用是為樹葉構件和樹枝構件聲明公共接口，並實現它們的默認行為。在透明式的組合模式中抽象構件還聲明訪問和管理子類的接口；在安全式的組合模式中不聲明訪問和管理子類的接口，管理工作由樹枝構件完成。
- 樹葉構件（Leaf）角色：是組合中的葉節點對象，它沒有子節點，用於實現抽象構件角色中 聲明的公共接口。
- 樹枝構件（Composite）角色：是組合中的分支節點對象，它有子節點。它實現了抽象構件角色中聲明的接口，它的主要作用是存儲和管理子部件，通常包含 Add()、Remove()、GetChild() 等方法。
應用場景
- 在需要表示一個對象整體與部分的層次結構的場合。
- 要求對用戶隱藏組合對象與單個對象的不同，用戶可以用統一的接口使用組合結構中的所有對象的場合。