剛看了看設計模式，真是費了好多的腦細胞。
想著想著就到了食堂。o(∩
_∩)o哈！
正是長身體的時候（大神勿噴），
一定要多吃點。於是我打了乙份公尺飯，然後又端著盛公尺飯的盤子買了乙份菜
，看著還不是很夠，就又端著這個盤子買了一條最愛吃的魚。
-----
裝飾模式！
五一要來了。回家轉轉，沒有小外甥的玩具怎麼行。
於是我去超市，推著購物車走了進去。三字經，恩不錯，收下了。玩具車，恩，不錯，收下了。一路上，推著購物車，把要買的東西就都放車裡了。推著購物車結賬就ok了
---裝飾模式！
等等，怎麼就是裝飾模式了？
你看，裝飾模式是什麼？
為已有功能動態地新增更多功能的一種方式。
也就是當系統
僅僅是為了滿足一些只在某種特定情況下才會執行的特殊行為，需要新的功能的時候，向舊的類中新增新的**。裝飾模式把要裝飾的功能放在單獨的類中，並讓這個類包裝它要裝飾的物件。當需要執行特殊行為時，客戶**就可以在執行時根據需要有選擇的按順序的使用裝飾功能包裝物件了。
讓我們結合情景一想一想。本來我是買了乙份公尺飯（已有功能），而我又想吃菜（特定情況的新需求），就在原有的盤子中新增菜。此處，菜是乙個類，用它來「包裝」我的晚飯。當然還可以用魚
用其他水果等來包裝我的晚飯。
我們看一段「化妝後」的裝飾模式的**。
飯 meal=new 飯("晚飯");
公尺飯rice=new公尺飯（）；
菜vegetables= new 菜();
魚fish = new 魚();
rice.decorate(meal);//此處是用rice來包裝meal,相當於打了乙份公尺飯
vegetables.decorate(rice);//用vegetables來包裝rice，相當於在盛公尺飯的盤子上又買菜
fish .decorate(vegetables);//fish包裝vegetables，相當於在盛公尺飯和菜的盤子上又買了魚
fish.show();//呈現出我的晚飯
以下，從整體上來了解一下。
此處如果只有乙個
concretecomponent
類而沒有抽象的
component
類，那麼
decorator
類可以是
concretecomponent
的乙個子類。同樣道理，如果只有乙個
concretedecorator
類，那麼就沒有必要建立乙個單獨的
decorator
類，而可以把
decorator
和concretedecorator
並成乙個類。
接下來為了讓我們更好的理解結構圖。再來看乙個大話設計模式中裝飾模式的例子「穿什麼有這麼重要」，小菜要去約會，正考慮穿什麼呢。
**結構圖為
此處是將上圖簡化了。直接讓服飾類
decorator
繼承人類
concretecomponent
就可。
還有一點很重要。設計模式中是有順序的，我們需要把所需功能按照正確的順序串聯起來進行控制。例如，加密資料和過濾詞彙都可以是資料持久化前的裝飾功能，若先加密在用過濾就會有問題。在例如，穿什麼對小菜都是裝飾，那先穿鞋在穿襪子就不大好了。。
裝飾模式，把類中的裝飾功能從類中搬移去除，可以簡化原有類。也有效地把類的核心職責和裝飾功能區分開來，而且可以去除重複的裝飾邏輯。
難得聽我說了這麼多，趕緊吃個夜宵去吧
~
設計模式 裝飾模式
裝飾模式，動態地給乙個物件新增一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。m 超級瑪麗 普通繼承模式實現 a 發鏢 能組合出七種功能 m1 a m4 a b b 變身 m2 b m5 a c c 無敵 m3 c m6 b c m7 a b m m1 a b 組合方法 new m2 m...
設計模式 裝飾模式
複習設計模式 裝飾模式 裝飾模式 在不修改已經存在的類的情況下，動態的新增新的功能，實現即插即用，開放關閉原則 public inte ce man public class batman implements man override public void killmonster public ...
設計模式 裝飾模式
裝飾模式是屬於結構型的設計模式。裝飾模式的定義 動態給乙個物件新增一些額外的職責，就增加功能來說，裝飾模式比生成子類更加靈活。裝飾模式的結構圖如下 適用性 1 在不影響其他物件的情況下，以動態，透明的方式給單個物件新增職責 2 處理那些可以撤銷的職責 3 當不能採用生成子類的方式進行擴充時。一種情況...