“Head First 設(shè)計模式“ ：裝飾模式

裝飾模式

    裝飾者模式：動態(tài)地將責(zé)任附加到對象上。若要擴展功能，裝飾者提供了比繼承更有彈性的替代方案。

    裝修模式的角色如下：

• 抽象構(gòu)件角色（Component）：給出一個抽象接口，以規(guī)范準備接收附加責(zé)任的對象。

• 具體構(gòu)件角色（Concrete Component）：定義將要接收附加責(zé)任的類。

• 裝飾角色（Decorator）：持有一個構(gòu)件（Component）對象的引用，并定義一個與抽象構(gòu)件接口一致的接口。

• 具體裝飾角色（Concrete Decorator）：負責(zé)給構(gòu)件對象“貼上”附加的責(zé)任。類圖如下：

    裝修模式的特點：

• 裝飾對象和真實對象有相同的接口。這樣客戶端對象就可以以和真實對象相同的方式和裝飾對象交互。

• 裝飾對象包含一個真實對象的引用（reference）。

• 裝飾對象接收所有來自客戶端的請求，它把這些請求轉(zhuǎn)發(fā)給真實的對象。

• 裝飾對象可以在轉(zhuǎn)發(fā)這些請求之前或之后附加一些功能。

• 這樣就確保了在運行時，不用修改給定對象的結(jié)構(gòu)就可以在外部增加附加的功能。

    裝修模式的缺點：

• 裝飾模式會導(dǎo)致設(shè)計中出現(xiàn)許多小類，如果過度使用，會使程序變得很復(fù)雜。
  

• 裝飾模式是針對抽象組件（Component）類型編程。但是，如果你要針對具體組件編程時，就應(yīng)該重新思考你的應(yīng)用架構(gòu)，以及裝飾者是否合適。當(dāng)然也可以改變Component接口，增加新的公開的行為，實現(xiàn)“半透明”的裝飾者模式。在實際項目中要做出較佳選擇。

    裝飾模式的使用場景：

• 適合對默認目標(biāo)實現(xiàn)中的多個接口進行排列組合調(diào)度

• 適合對默認目標(biāo)實現(xiàn)進行選擇性擴展

• 適合對默認目標(biāo)實現(xiàn)未知或者不易擴展的情況。

    實例1：咖啡店有好幾種咖啡，每一種都是自己的價格，成分等，類圖如下；

    問題的產(chǎn)生：咖啡可以放些糖等調(diào)料，調(diào)料種類多，新增了N個子類來對應(yīng)咖啡，價格，調(diào)料之間的關(guān)系，后期維護有了很大的挑戰(zhàn)，類圖如下：

    解決：我們可以用裝飾模式來解決，最終的類圖如下：

    實例2：擴展JAVA里的I/O，讀取文件里的數(shù)據(jù)，并轉(zhuǎn)成大寫字母輸出

    分析：JDK里I/O框架用到了適配器模式，類圖如下：

    說明：抽象構(gòu)建角色（InputStream），裝飾角色（FilterInputStream），具體裝飾（BufferdInputStream等），具體構(gòu)建角色（FileInputStream等）

    實現(xiàn)：我們看類圖，我們繼承FilterInputStream，覆蓋掉read方法就能滿足這個需求了。

    設(shè)計原則：類應(yīng)該對擴展開放，對修改關(guān)閉。