裝飾模式
裝飾者模式：動態地將責任附加到對象上。若要擴展功能，裝飾者提供了比繼承更有彈性的替代方案。
裝修模式的角色如下：
抽象構件角色（Component）：給出一個抽象接口，以規範準備接收附加責任的對象。
具體構件角色（Concrete Component）：定義將要接收附加責任的類。
裝飾角色（Decorator）：持有一個構件（Component）對象的引用，並定義一個與抽象構件接口一致的接口。
具體裝飾角色（Concrete Decorator）：負責給構件對象“貼上”附加的責任。類圖如下：
裝修模式的特點：
裝飾對象和真實對象有相同的接口。這樣客戶端對象就可以以和真實對象相同的方式和裝飾對象交互。
裝飾對象包含一個真實對象的引用（reference）。
裝飾對象接收所有來自客戶端的請求，它把這些請求轉發給真實的對象。
裝飾對象可以在轉發這些請求之前或之後附加一些功能。
這樣就確保了在運行時，不用修改給定對象的結構就可以在外部增加附加的功能。
裝修模式的缺點：
裝飾模式會導致設計中出現許多小類，如果過度使用，會使程序變得很複雜。
裝飾模式是針對抽象組件（Component）類型編程。但是，如果你要針對具體組件編程時，就應該重新思考你的應用架構，以及裝飾者是否合適。當然也可以改變Component接口，增加新的公開的行爲，實現“半透明”的裝飾者模式。在實際項目中要做出較佳選擇。
裝飾模式的使用場景：
適合對默認目標實現中的多個接口進行排列組合調度
適合對默認目標實現進行選擇性擴展
適合對默認目標實現未知或者不易擴展的情況。
實例1：咖啡店有好幾種咖啡，每一種都是自己的價格，成分等，類圖如下；
問題的產生：咖啡可以放些糖等調料，調料種類多，新增了N個子類來對應咖啡，價格，調料之間的關係，後期維護有了很大的挑戰，類圖如下：
解決：我們可以用裝飾模式來解決，最終的類圖如下：
實例2：擴展JAVA裏的I/O，讀取文件裏的數據，並轉成大寫字母輸出
分析：JDK裏I/O框架用到了適配器模式，類圖如下：
說明：抽象構建角色（InputStream），裝飾角色（FilterInputStream），具體裝飾（BufferdInputStream等），具體構建角色（FileInputStream等）
實現：我們看類圖，我們繼承FilterInputStream，覆蓋掉read方法就能滿足這個需求了。
設計原則：類應該對擴展開放，對修改關閉。