設計模式筆記 Decorator模式

2021-07-12 03:49:56 字數 1531 閱讀 7457

裝飾模式,通過組合而不是繼承的方式,動態地給類增加功能的方法!

這句話不好理解,

邊看下圖例子邊說話吧:streams是大多數i / o裝置的基礎抽象結構,它提供了將物件轉換成為位元組或字元流的操作介面,使我們可以將乙個物件轉變成乙個檔案或記憶體中的字串。乙個簡單直接的方法是定義乙個抽象的stream類,它有兩個子類memorystream與filestream。但假定我們還希望能夠做下面一些事情(新增功能):

• 用不同的壓縮演算法(行程編碼, lempel-ziv等)對資料流進行壓縮。

• 將流資料簡化為7位a s c i i碼字元,這樣它就可以在a s c i i通道上傳輸。

現在來理解上面那句話:如果要用繼承的方式完成上面的功能,那基本上要從stream繼承出4個類:ascii7memeorystream, ascii7filestream, compressingmemorystream, compressingfilestream。如果再加些別的功能,那麼子類的功能不堪設想,其實像這種笛卡爾積種組合方案的設計需求,是可以用某種模式優雅地重構的。

由uml圖可知,streamdecorator類中組合了stream類指標變數,在建構函式中傳參初始化!同時,它也繼承了stream類,這我不太理解,可能是要保持同樣的介面吧,因為該模式要求streamdecorator類和stream類必須有相同的操作介面,比如上例的handlebuffefull(), 這樣繼承的話省去了重寫介面的麻煩?

還有所謂的動態增加功能,也就是在執行時新增,不是像繼承那樣一下子在編譯時就都靜態新增進來,導致子類膨脹。這就很容易讓人想到c++多型技術!

還有一點就是,為什麼decorator還要派生出一些具體的子類?這是為了對新增功能進行模組化封裝:壓縮功能用乙個子類,轉碼功能用乙個子類!因為是額外新增功能,所以這些子類的handlebufferfull()函式中除了要呼叫stream類的handlebufferfull()外,還要進行額外的操作。這裡是解決問題的重點!形如:

void ascii7stream::handlebufferfull()

這裡的額外操作函式一般來說只對該子類有意義,因為該子類就是為額外操作而生的嘛,所以它一般可以設為私有!

使用者**怎麼使用呢?

stream * stm = new memorystream();

streamdecorator *dec = new streamdecorator(stm);

dec->handlebufferfull();

更妙的是我們可以建立filestream類,它首先將資料壓縮,然後將壓縮了的二進位制資料轉換成為7位ascii碼:

stream* astream = new ascii7stream (

new compressingstream(

new filestream("

afilestream"))

);

Decorator設計模式

雖然設計模式分得太細會有過度的趨勢,decorator某種程度上也是一種facade模式。但是實現起來還是比較漂亮的。而後面那個人的class arlist list,ilist的方法就不是decorator。它沒有乙個內部的list。這樣 however,now all of list s met...

設計模式 decorator模式

裝飾者模式體現了 敏捷開發思想中的 對類要 開放擴充套件,關閉修改.例子 乙個person主類 若干裝飾品類 紅衣服,藍衣服,藍鞋子,紅鞋子 測試 new乙個person 給他穿上紅衣服藍鞋子 code person介面 public inte ce ipersonperson類 package c...

設計模式 decorator模式

兩點 目的 在不改變被裝飾類功能的前提下增加新功能 特點 繼承是子類和父類強耦合,橋接是低耦合 例子 class print 抽象介面 virtual int getcolumns virtual int getrows virtual string getrowcontent int row el...