把所需的功能按正確的順序串聯起來進行控制。
Decorator:動態的給一個對象添加一些額外的職責,就增加功能來說,裝飾模式比生成子類更加靈活。
abstract class Component{ public abstract void Operation();}class ConcreteComponent extends Component{ @override public void Operation() { 具體對象的操作; }}abstract class Decorator extends Component{ PRotected Component component; //設置component public void setComponent(Component component) { this.component = component; } //重寫Operation(),實際執行的是Component的Operation()。 @override public void Operation() { if (component != NULL) component.Operation(); }}class ConcreteDecoratorA extends Decorator{ //本類獨有的功能,以區別ConcreteDecoratorB private string addedState; //首先運行原Component的Operation(),再執行本類的功能,如addedState,相當于對原Component進行了裝飾。 @override public void Operation() { super.Operation(); addedState = “New State”; 具體裝飾對象A的操作; }}class ConcreteDecoratorB extends Decorator{ //首先運行原Component的Operation(),再執行本類的功能,如AddedBehavior(),相當于對原Component進行了裝飾。 @override public void Operation() { super.Operation(); AddedBehavior(); 具體裝飾對象B的操作; } private void AddedBehavior(){ }}static void main(string[] args){ ConcreteComponent c = new ConcreteComponent(); ConcreteDecoraterA da = new ConcreteDecoraterA(); ConcreteDecoraterB db = new ConcreteDecoraterB(); da.setComponent(c); db.setComponent(da); db.Operation();}裝飾模式是利用setComponent來對對象進行包裝。
每個裝飾對象的實現就和如何使用這個對象分開了,每個裝飾對象只關心自己的功能,不需要關心如何被添加到對象鏈當中。
如果只有一個ConcreteComponent類而沒有抽象的Component類,那么Decorator類可以是ConcreteComponent的一個子類。
同理,如果只有一個ConcreteDecorator類,那么就沒有必要建立一個單獨的Decorator類,而可以把Decorator和ConcreteDecorator的責任合并成一個類。
裝飾模式總結:
裝飾模式是為已有功能動態的添加更多功能的一種方式。
當系統需要新功能的時候,是向舊的類中添加新的代碼
這些新加的代碼通常裝飾了原有類的核心職責或主要行為
在主類中加入了新的字段、新的方法和新的邏輯,從而增加了主類的復雜度。
而這些新加入的東西僅僅是為了滿足一些只在某種特定情況下才會執行的特殊行為的需要。
裝飾器模式提供了一個非常好的解決方案,它把每個要裝飾的功能放在單獨的類中,并讓這個類包裝它所要裝飾的對象,因此,當需要執行特殊行為時,客戶代碼就可以在運行時根據需要有選擇的、按順序的使用裝飾功能包裝對象了。
裝飾模式的優點:
把類中的裝飾功能從類中搬移去除,這樣可以簡化原有的類。
有效的把類的核心職責和裝飾功能區分開了,而且可以去除相關類中重復的裝飾邏輯。
新聞熱點
疑難解答