設計模式之裝飾器模式

定義

Attach additional responsibilities to an object dynamically keeping the same interface.Decorators provide a flexible alternative to subclassing for extending functionality.（動態地給一個對象添加一些額外的職責。 就增長功能來講，裝飾模式相比生成子類更爲靈活

UML類圖

角色

• Component 抽象構件，就是裝飾器與被裝飾類共有的抽象。
• ConcreteComponent 具體構件，就是被裝飾類
• Decorator 裝飾器抽象，就是裝飾器的抽象
• ConcreteDecorator 裝飾器的具體實現

應用

應用中一般代碼如：

裝飾類實現：

//構造方法，初始化成員變量爲裝飾類
public ConcreteDecorator1(Component component){
   //抽象裝飾器中定義的構造方法，初始化被裝飾類到成員變量
   super(component);
}
public void operate(){
//這裏能夠添加一些功能加強
this.component.operate()
//這裏能夠添加一些功能加強
}

場景類應用：

Component component = new ConcreteComponent();
//第一次修飾 
component = new ConcreteDecorator1(component);
//第二次修飾 
component = new ConcreteDecorator2(component);
//修飾後運行 
component.operate();

思考

裝飾器模式最大的好處是動態擴展一類對象的功能，而且能夠應用嵌套裝飾無限擴展下去。 這是單單用繼承來加強父類行爲這種方式來擴展遠比不了的嗎，由於繼承是靜態的，擴展哪一個類都已經在定義類的時候決定了。

與代理模式的對比

代理模式在前篇梳理過： 設計模式之代理模式。

總結下二者的區分：

代理模式對於整個系統來講是控制了真實對象的訪問，咱們每每只須要使用代理類完成相關業務功能就好了，被代理類相對透明。 若是是裝飾器模式，那麼咱們須要關注的是被裝飾的類須要添加什麼裝飾這個過程，系統中的代碼仍是得依賴被裝飾對象。