我們經常會遇到這種問題,當乙個類出現非常多的選擇,比如 咖啡,要加 糖、抹茶、香草、牛奶……,那麼多調味品,在這種情況下,考慮通過繼承的方式是否合理?你會得到 很多種咖啡類,牛奶咖啡、抹茶咖啡、牛奶椰蓉咖啡、香草黑糖咖啡、曲奇巧克力蛋奶咖啡……,好像很不靠譜對吧?
發現了 上面的子類**問題後,你可能會問,我需要定義那麼多的子類嗎? 咖啡就是咖啡,其他的只是酌料而已。
裝飾者模式相當於在類外面加上包裝,生成新的類,這樣做的好處 一是 減少了子類的數量(沒有了組合類),二是可以在執行時動態組合,更加靈活。
還是以 咖啡為例,通過**來進行說明:
// caffe抽象基類 - component
class icaffe
;// caffe實現類 - concretecomponent
class caffe : public icaffe;};
// decortaor
class decorator : public icaffe
public:
virtual float getprice()
protected:
icaffe* m_pcomponent;
};// concretedecorator
class mochacaffe : public decorator
public:
virtual float getprice()
};
裝飾者模式通過相同的抽象基類,能夠實現多層的包裝,這樣做的缺點是 其內容定義往往不是很清晰,就好像我們收到乙個程式設計師朋友寄來的禮物,拆開 天貓的塑膠袋,裡面是個紙箱子,拆開紙箱子裡面是乙個盒子,拆開盒子發現裡面是乙個信封,拆開信封發現裡面有張紙,清晰得寫著四個大字:「hello world!」
// caffe類
class caffe
};// 修飾元件類
enum dressing_type
class dressing
;// 具體實現類
class dressedcaffe : public caffe
protected:
caffe m_caffe;
vectorm_vecdressing;
};
只需要擴充套件dressing的屬性定義即可,這裡不去比較哪種方案的優劣,其實每個人都有自己的**習慣,符合自己的才是最好的,ps:設計模式裡面真正應用最多的也就那麼幾種,用之前先要考慮這是否必要,強用設計模式 著實是初學者 乙個非常大的誤區! 設計模式 9 裝飾模式
裝飾模式可以動態向乙個現有的物件新增新的功能,同時又不改變其結構。就增加功能來說,使用繼承的方式生成子類也可以達到目的,但隨著擴充套件功能的不斷增加,子類的數量會快速膨脹,而裝飾模式提供了一種更加靈活的方案。gof對裝飾模式的描述為 attach additional responsibilitie...
設計模式9 裝飾器模式
裝飾器模式 decorator pattern 允許向乙個現有的物件新增新的功能,同時又不改變其結構。這種型別的設計模式屬於結構型模式,它是作為現有的類的乙個包裝。這種模式建立了乙個裝飾類,用來包裝原有的類,並在保持類方法簽名完整性的前提下,提供了額外的功能。裝飾器模式,從某種角度上說,可能更適合用...
設計模式 9 裝飾者模式
動態地將責任附加到物件上,若要擴充套件功能,裝飾者比繼承更有彈性 裝飾者將被裝飾聚合到自己內部,雙方都繼承共同的抽象方法,往往是被裝飾者只需要完成自己的本質工作,裝飾者在整合的被裝飾者功能基礎之上新增自己的邏輯。下面以飲品店咖啡和咖啡配料組合例子作為案例說明 public abstract clas...