結構型設計模式是從程式的結構上解決模組之間的耦合問題。包括以下七種模式：

1.Adapter介面卡模式：Adapter模式通過類的繼承或者物件的組合側重於轉換已有的介面，類介面卡採用“多繼承”的實現方式，帶來了不良的高耦合，所以一般不推薦使用。物件介面卡採用“物件組合”的方式，更符合鬆耦合精神。

例如：筆記本電源介面卡，可以將220v轉化為適合筆記本使用的電壓。

2.Bridge橋接模式：將抽象部分與實現部分分離，使它們都可以獨立的變化。減少因變化帶來的程式碼的修改量。

例如：經典例子,電燈開關，開關的目的是將裝置開啟或關閉，產生的效果不同。

3.Composite組合模式：將物件組合成樹形結構以表示“部分-整體”的層次結構。Composite模式使得客戶對單個物件和組合物件的使用具有一致性。從而解決了解決客戶程式與複雜物件容器的解耦，即：通過繼承統一的介面，我們可以將容器物件及其子物件看成同一類物件使用，以減少物件使用中的複雜度。

例如：讓使用者一致地使用單個物件和組合物件，1+2和（1+1）+（2*3）都是合法的表示式。 單個與整體都可以進行加法運算子的操作。

4.Decorator裝飾模式：動態地給一個物件新增一些額外的職責。就增加功能來說，Decorator模式相比生成子類更為靈活。[GOF 《設計模式》]Decorator模式採用物件組合而非繼承的手法，實現了在執行時動態的擴充套件物件功能的能力，而且可以根據需要擴充套件多個功能，避免了單獨使用繼承帶來的“靈活性差”和“多子類衍生問題”。同時它很好地符合面向物件設計原則中“優先使用物件組合而非繼承”和“開放-封閉”原則。

例如：一幅畫，可以直接掛到牆上，也可以加上框架和鑲上玻璃後，再掛到牆上。

5.Facade外觀模式：為子系統中的一組介面提供一個一致的介面，簡化介面。

例如：我們撥打10086，可以辦理，彩鈴，手機報，全時通等業務（子物件），而10086則是為子物件所使用的一致介面。

6.Flyweight享元模式：運用共享技術有效地支援大量細粒度的物件。[GOF 《設計模式》]。 解決：　面向物件的思想很好地解決了抽象性的問題，一般也不會出現效能上的問題。但是在某些情況下，物件的數量可能會太多，從而導致了執行時的代價。那麼我們如何去避免大量細粒度的物件，同時又不影響客戶程式使用面向物件的方式進行操作，享元模式的出現恰好解決了該問題。

　例如：公共交換電話網（PSTN）是享元的一個例子。有一些資源例如撥號音發生器、振鈴發生器和撥號接收器是必須由所有使用者共享的。當一個使用者拿起聽筒打電話時，他不需要知道使用了多少資源。對於使用者而言所有的事情就是有撥號音，撥打號碼，撥通電話。

7.Proxy代理模式：為其他物件提供一種代理以控制這個物件的訪問。解決直接訪問某些物件是出現的問題。

例如：律師本身就是我們維權的一個代理！

小總結：從程式碼的角度看Adapter介面卡模式和Proxy代理模式有些類似，前者是解決現有物件在新的環境中所遇到的問題，後者是解決直接訪問物件時出現的問題，這兩種模式從使用角度看都是解決直接訪問物件時出現的問題，只是含義不十分相同。