第八個設計模式
意圖
動態地給乙個物件新增一些額外的職責。有時候我們需要給某個物件而不是整個類新增一些功能。
適用性
結構
參與者
component：定義乙個物件介面，可以給這些物件動態地新增職責。
concretecomponent： 定義乙個物件，可以給這個類的物件新增一些職責
decorator:維持乙個指向component物件的指標，並定義乙個與component介面一致的介面
concretedecorator:向元件新增職責。
實現
#include
#include
#include
using namespace std;
//抽象類tank
class tank
//具體的坦克的裝飾類
virtual ~decorator()
void run()
};
class infrareddecorator: public decorator
virtual ~infrareddecorator()
string get_infrared() const
void run()
};
class amphibiandecorator:public decorator
~amphibiandecorator()
string get_amphibian() const
public:
void
run()
};
int main(int argc, char **argv)
1.需要擴充套件乙個類的功能，或給乙個類增加附加責任。
2.需要動態地給乙個物件增加功能，這些功能可以再動態地撤銷。
3.需要增加由一些基本功能的排列組合而產生的非常大量的功能，從而使繼承關係變得不現實。
優點：
1. decorator模式與繼承關係的目的都是要擴充套件物件的功能，但是decorator可以提供比繼承更多的靈活性。
2. 通過使用不同的具體裝飾類以及這些裝飾類的排列組合，設計師可以創造出很多不同行為的組合。
缺點：
1. 這種比繼承更加靈活機動的特性，也同時意味著更加多的複雜性。
2. 裝飾模式會導致設計中出現許多小類，如果過度使用，會使程式變得很複雜。
3. 裝飾模式是針對抽象元件（component）型別程式設計。但是，如果你要針對具體元件程式設計時，就應該重新思考你的應用架構，以及裝飾者是否合適。當然也可以改變component介面，增加新的公開的行為，實現「半透明」的裝飾者模式。在實際專案中要做出最佳選擇。
參考於：
Decorator 裝飾 設計模式
宣告 本博文篇幅短，適合review。一 概念 裝飾模式是在不必改變原類檔案和使用繼承的情況下，動態地擴充套件乙個物件的功能。它是通過建立乙個包裝物件，也就是裝飾來包裹真實的物件。二 結構模式圖 三 例子 四 優缺點 1 優點 a decorator模式與繼承關係的目的都是要擴充套件物件的功能，但是...
設計模式 Decorator裝飾模式
decorator裝飾模式是一種結構型模式，它主要是解決 過度地使用了繼承來擴充套件物件的功能 由於繼承為型別引入的靜態特質，使得這種擴充套件方式缺乏靈活性 並且隨著子類的增多 擴充套件功能的增多 各種子類的組合 擴充套件功能的組合 會導致更多子類的膨脹 多繼承 繼承為型別引入的靜態特質的意思是說以...
設計模式 裝飾模式（Decorator ）
讓我們來理解一下這句話。我們來設計 門 這個類。假設你根據需求為 門 類作了如下 定義 現在，在系統的乙個地方需要乙個能夠報警的door，你來怎麼做呢？你或許寫乙個door的子類alarmdoor，在裡面新增乙個子類獨有的方法alarm 嗯，那在使用警報門的地方你必須讓客戶知道使用的是警報門，不然無...