設計模式-結構型

一． 適配器模式

配器模式（Adapter Pattern）是做爲兩個不兼容的接口之間的橋樑。這種類型的設計模式屬於結構型模式，它結合了兩個獨立接口的功能。這個模式將一個類的接口轉換成客戶但願的另一個接口。適配器模式使得本來因爲接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做。

實現方式是，適配器繼承或依賴已有的對象，實現想要的目標接口。

須要注意的是: 適配器不是在詳細設計時添加的，而是解決正在服役的項目的問題。

二． 橋接模式

橋接（Bridge）是用於把抽象化與實現化解耦，使得兩者能夠獨立變化。這種類型的設計模式屬於結構型模式，它經過提供抽象化和實現化之間的橋接結構，來實現兩者的解耦。

橋接模式將繼承關係轉換爲關聯關係，而且這種關聯關係是創建在抽象層，從而下降了類與類之間的耦合，減小了代碼編寫量。

例子：畫圖，這裏有一個畫筆，能夠畫正方形、長方形、圓形（這個你們都知道怎麼作吧，我就不解釋了）。可是如今咱們須要給這些形狀進行上色，這裏有三種顏色：白色、灰色、黑色。這裏咱們能夠畫出3*3=9中圖形：白色正方形、白色長方形、白色圓形……，到這裏了咱們幾乎到知道了這裏存在兩種解決方案：方案一：爲每種形狀都提供各類顏色的版本。方案二：根據實際須要對顏色和形狀進行組合。

使用場景：一、若是一個系統須要在構件的抽象化角色和具體化角色二者之間增長更多的靈活性，避免在兩個層次之間創建靜態的繼承聯繫，經過橋接模式可使它們在抽象層創建一個關聯關係。二、對於那些不但願使用繼承或由於多層次繼承致使系統類的個數急劇增長的系統，橋接模式尤其適用。三、一個類存在兩個獨立變化的維度，且這兩個維度都須要進行擴展。

三．過濾器模式

過濾器模式（Filter Pattern）或標準模式（Criteria Pattern）是一種設計模式，這種模式容許開發人員使用不一樣的標準來過濾一組對象，經過邏輯運算以解耦的方式把它們鏈接起來。這種類型的設計模式屬於結構型模式，它結合多個標準來得到單一標準。

不過這樣也算一種模式？？？

四． 組合模式

組合模式實現的最關鍵的地方是——簡單對象和複合對象必須實現相同的接口。這就是組合模式可以將組合對象和簡單對象進行一致處理的緣由。將對象組合成樹形結構以表示"部分-總體"的層次結構。組合模式使得用戶對單個對象和組合對象的使用具備一致性。

例子：手遊引擎裏面的各個組件能夠相互組合，造成樹狀結構。

五． 裝飾器模式

這種模式建立了一個裝飾類，用來包裝原有的類，並在保持類方法簽名完整性的前提下，提供了額外的功能。

在這個模式中，裝飾者和被裝飾者會繼承同一個基類，實現同一個接口。裝飾者會依賴於被裝飾者，而後裝飾者之間也會相互依賴。在裝飾的時候，裝飾者會先調用前一個裝飾者的裝飾方法，再開始加上本身的裝飾功能。

在我上一個手遊項目中，我曾經用這個模式實現過一個彈提示框的功能，經過將提示框分爲幾個部分，每一個部分都是一個裝飾者，當我用代碼實現了每一個部分以後，再創建一個數字到每一個類名的映射，策劃就能夠本身根據須要，配置本身須要的部分。

六． 外觀模式

外觀模式（Facade Pattern）隱藏系統的複雜性，並向客戶端提供了一個客戶端能夠訪問系統的接口。這種類型的設計模式屬於結構型模式，它向現有的系統添加一個接口，來隱藏系統的複雜性。

這個沒什麼好說的，就是puremvc中的facade，就是向外爲一個系統或者幾個系統提供一些對外的接口。外界只與facade進行交互。

七． 享元模式

享元模式（Flyweight Pattern）主要用於減小建立對象的數量，以減小內存佔用和提升性能。這種類型的設計模式屬於結構型模式，它提供了減小對象數量從而改善應用所需的對象結構的方式。

就是對象池的技術。

八． 代理模式

代理模式主要解決，在直接訪問對象時帶來的問題，好比說：要訪問的對象在遠程的機器上。在面向對象系統中，有些對象因爲某些緣由（好比對象建立開銷很大，或者某些操做須要安全控制，或者須要進程外的訪問），直接訪問會給使用者或者系統結構帶來不少麻煩，咱們能夠在訪問此對象時加上一個對此對象的訪問層。

和其餘模式的區別: 一、和適配器模式的區別：適配器模式主要改變所考慮對象的接口，而代理模式不能改變所代理類的接口。 二、和裝飾器模式的區別：裝飾器模式爲了加強功能，而代理模式是爲了加以控制。

完。