裝飾模式（decorator）：
動態地給乙個物件新增一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。
1. component是定義乙個物件介面，可以給這些物件動態地新增職責。concretecomponent是定義乙個具體的物件，也可以給這個物件新增一些職責。decorator，裝飾抽象類，繼承了component，從外類來擴充套件component類的功能，但對於component來說，是無需知道decorator的存在的。至於concretecomponent就是具體的裝飾物件，起到給component新增職責的功能。
2. 裝飾模式是利用setcomponent來對物件進行包裝的。這樣每個裝飾物件的實現就和如何使用這個物件分離開了，每個裝飾物件只關心自己的功能，不需要關心如何被新增到物件鏈中。
3. 如果只有乙個concretecomponent類而沒有抽象的component類，那麼decorator類可以是concretecomponent的乙個子類，同樣道理，如果只有乙個concretedecorator類，那麼就沒有必要建立乙個單獨的decorator類，而可以把decorator和concretedecorator的責任合併成乙個類。
接下來就是用**實現一下上面的uml結構圖。
裝飾模式實現**：
#pragma once
#include using namespace std;
class ccomponent
;class cconcretecomponent : public ccomponent
}};class cconcretedecoratora : public cdecorator
總結：
裝飾模式是為已有功能動態地新增更多功能的一種方式。當系統需要新功能的時候，是向舊的類中新增新的**。這些新加的****通常裝飾了原有類的核心職責或者主要行為，在主類中加入了新的字段，新的昂發和新的邏輯，從而增加了主類的複雜度，而這些新加入的東西僅僅是為了滿足一些只在某種特定情況下才會執行的特殊行為的需要。而裝飾模式卻提供了乙個非常好的解決方案，它把每個要裝飾的功能放在單獨的類中，並讓這個類包裝它所要裝飾的物件，因此。當需要執行特殊行為時，客戶端**就可以在執行時根據需要有選擇地，按順序地使用裝飾功能包裝物件了。
那麼也就是裝飾模式的優點是有效地吧類的核心職責和裝飾功能區分開了。而且可以去除相關類中重複裝飾的邏輯。
至於缺點，書上沒有說，其實很容易發現，使用者無論裝飾什麼，前提是必須知道所有衣服吧，當前的這個模式是使用者必須把衣服new出來（當然可以工廠優化，不過這樣這個模式太繁瑣了），以至於增加了使用者和改功能實現模組之間的耦合度。
設計模式 裝飾模式
裝飾模式，動態地給乙個物件新增一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。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...
設計模式 裝飾模式
剛看了看設計模式，真是費了好多的腦細胞。想著想著就到了食堂。o o哈！正是長身體的時候 大神勿噴 一定要多吃點。於是我打了乙份公尺飯，然後又端著盛公尺飯的盤子買了乙份菜 看著還不是很夠，就又端著這個盤子買了一條最愛吃的魚。裝飾模式！五一要來了。回家轉轉，沒有小外甥的玩具怎麼行。於是我去超市，推著購物...
設計模式 裝飾模式
複習設計模式 裝飾模式 裝飾模式 在不修改已經存在的類的情況下，動態的新增新的功能，實現即插即用，開放關閉原則 public inte ce man public class batman implements man override public void killmonster public ...