讓我們來理解一下這句話。我們來設計「門」這個類。假設你根據需求為「門」類作了如下
定義：
現在，在系統的乙個地方需要乙個能夠報警的door，你來怎麼做呢？你或許寫乙個door的子類alarmdoor，在裡面新增乙個子類獨有的方法alarm()。嗯，那在使用警報門的地方你必須讓客戶知道使用的是警報門，不然無法使用這個獨有的方法。而且，這個還違反了liskov 替換原則。
也許你要說，那就把這個方法新增到door 裡面，這樣不就統一了？但是這樣所有的門都必須有警報，至少是個「啞巴」警報。而當你的系統僅僅在一兩個地方使用了警報門，這明顯是不合理的——雖然可以使用預設介面卡來彌補一下。
這時候，你可以考慮採用裝飾模式來給門動態的新增些額外的功能。
下面我們來看看裝飾模式的組成，不要急著去解決上面的問題，到了下面自然就明白了！
1) 抽象構件角色（component）：定義乙個抽象介面，以規範準備接收附加責任的物件。
2) 具體構件角色(concrete component)：這是被裝飾者，定義乙個將要被裝飾增加功能的類。
3) 裝飾角色(decorator)：持有乙個構件物件的例項，並定義了抽象構件定義的介面。
4) 具體裝飾角色(concrete decorator)：負責給構件新增增加的功能。
看下裝飾模式的類圖：
圖中 concretecomponent 可能繼承自其它的體系，而為了實現裝飾模式，他還要實現component 介面。整個裝飾模式的結構是按照組合模式來實現的——兩者都有類似的結構圖，都基於遞迴組合來組織可變數目的物件。但是兩者的目的是截然不同的，組合（composite）模式側重通過遞迴組合構造類，使不同的物件、多重的物件可以「一視同仁」；而裝飾（decorator）模式僅僅是借遞迴組合來達到定義中的目的。
//抽象構件角色--component
public
inte***ce
shape
//具體構件角色--concrete componenta
public
class
circle
implements
shape
}//具體構件角色--concrete componentb
public
class
rectangle
implements
shape
}//裝飾角色--decorator
public
abstract
class
shapedecorator
implements
shape
public
void
draw()
}//具體裝飾角色--concrete decorator
public
class
redshapedecorator
extends
shapedecorator
@override
public
void
draw()
private
void
setredborder(shape decoratedshape)
}//客戶端
public
class
decoratorpatterndemo
}
circle with normal border
shape: circle
circle of red border
shape: circle
border color: red
rectangle of red border
shape: rectangle
border color: red
設計模式 裝飾模式
裝飾模式，動態地給乙個物件新增一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。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 ...