動態地給一個對象添加一些額外的職責。就增加功能來說,Decorator模式相比生成子類更
為靈活。
有時我們希望給某個對象而不是整個類添加一些功能。例如,一個圖形用戶界面工具箱允許
你對任意一個用戶界面組件添加一些特性,例如邊框,或是一些行為,例如窗口滾動。
使用繼承機制是添加功能的一種有效途徑,從其它類繼承過來的邊框特性可以被多個子類的
實例使用。但這種方法不夠靈活。因為邊框的選擇是靜態的,用戶不能控制對組件加邊框的
方式和時機。
一種極為靈活的方式是將組件嵌入另一個個對象中,由這個對象添加邊框。我們稱這個嵌入
的對象為裝飾。這個裝飾與它所裝飾的組件的接口一致,因此它對使用該組件的客戶透明。
它將客戶請求轉發給該組件,并且可能在轉發前后執行一些額外的動作(例如畫一個邊框)。
透明性使得你可以遞歸的嵌套多個裝飾,從而可以添加任意多的功能。
適用性:
1、在不影響其它對象的情況下,以動態、透明的方式給單個對象添加職責。
2、處理那些可以撤消的職責。
3、當不能采用生成子類的方法進行擴充時。一種情況是,可能有大量獨立的擴展,為支持
每一種組合將產生大量的子類,使得子類數目呈爆炸性增長。另一種情況可能是因為類定義
被隱藏,或類定義不能用于生成子類。
使用Decorator模式應注意以下幾點:
1、接口的一致性:裝飾對象的接口必須與它所裝飾的Component的接口是一致的。因此,所有
的ConcreteDecorator類必須有一個公共的父類(至少在C++中如此)
2、省略抽象的Decorator類:當你僅需要添加一個職責時,沒有必要定義抽象Decorator類,你常
常需要處理現存的類層次結構而不是設計一個新系統,這時你可以把Decorator的Component轉發
請求的職責合并到ConcreteDecorator中。
3、保持Component類的簡單性: 為了保證接口的一致性,組件和裝飾必須有一個公共的Component
父類。因此保持這個類的簡單性是很重要的,即,它應集中于定義接口而不是存儲數據。對數據表示
的定義應延遲到子類中,否則Component類會變得過于復雜和龐大,因而難以大量使用。賦予Component
太多的功能也使得,具體的子類有一些它們并不需要的功能的可能性大大增加。
4、改變對象外殼與改變對象內核。 我們可以將Decorator看作一個對象的外殼。它可以改變這個對象
的行為。另外一種方法是改變對象的內核。例如,Strategy模式就是一個用于改變內核的很好的模式。
當Component類原本就很龐大時,使用Decorator模式的代價太高,Strategy模式相對更好一些。
由于Decorator模式僅從外部改變組件,因此組件無需對它的裝飾有任何了解;也就是說,這些裝飾對該
組件是透明的。
相對而言這個模式比較簡單,以下為書中相關代碼,略作修改。



















































































































更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
