java之裝飾器模式

Decorator Pattern(裝飾器模式)，定義：Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.(動態地給一個對象添加一些額外的職責。就增加功能來說，裝飾模式相比生成子類更為靈活)

裝飾器的通用視圖：

 

上圖四個角色解釋一下：

1.Component抽象構件：

Component是一個接口或者一個抽象類，就是定義我們最核心的對象，也就是最原始的對象，最高層次的抽象，統一整個裝飾器系統，用於裝飾器之間溝通的橋梁，就像II/O流中的InputStream，OutputStream一樣

2.ConcreteComponent具體構件

ConcreteComponent是最核心，最原始，最基本的接口或者抽象類的實現，你要裝飾的就是它，裝飾的源頭，你裝飾的最底層，就像I/O流一樣，這就直接跟底層打交道的節點流，就比如FileInputStream

3.Decorator 裝飾角色

一般是一個抽象類，實現接口或者抽象方法，它並不一定有抽象方法，但在它的屬性里必須有一個private變量指向Component抽象構件，一般是用構造器初始化。就像I/O流中的FilterInputStream

4.ConcreteDecoratorA，ConcreteDecoratorB具體的裝飾器角色，這就是要將我們之間建的最核心，最原始，最基礎的東西裝飾成東西或者其他的東西，就像I/O中的BufferedInputStream，DataInputStream等。

下面給出一個簡單的例子：

package decorator;
//抽象構件
public interface Component
{
    void operation();
}
//具體的抽象構件的實現
public class ConcreteComponent implements Component
{

    /** { @inheritDoc } */
    @Override
    public void operation()
    {
        System.out.println("我是ConcreteComponent，是最原始的實現類，我處於最底層");
    }
    
}
//抽象裝飾器
public abstract class Decorator implements Component
{
    private Component component;

    /** 
     * @param component 
     */ 
    public Decorator(Component component)
    {
        this.component = component;
    }
    
    /** { @inheritDoc } */
    @Override
    public void operation()
    {
        component.operation();
    }
}
//具體裝飾器A
public class ConcreteDecoratorA extends Decorator
{

    /** 
     * @param component 
     */ 
    public ConcreteDecoratorA(Component component)
    {
        super(component);
    }
    
    public void methodA() 
    {
        System.out.println("我是ConcreteDecoratorA，添加的新功能");
    }
    
    /** { @inheritDoc } */
    @Override
    public void operation()
    {
        methodA();
        super.operation();
        System.out.println("ConcreteDecoratorA的operation執行完畢");
    }

}
//具體裝飾器B
public class ConcreteDecoratorB extends Decorator
{

    /** 
     * @param component 
     */ 
    public ConcreteDecoratorB(Component component)
    {
        super(component);
    }
    
    public void methodB() 
    {
        System.out.println("我是ConcreteDecoratorB，添加的新功能");
    }
    
    /** { @inheritDoc } */
    @Override
    public void operation()
    {
        methodB();
        super.operation();
        System.out.println("ConcreteDecoratorB的operation執行完畢");
    }

}
 93 //測試類
public class Demo
{
    public static void main(String[] args)
    {
        Component component = new ConcreteComponent();
        
        ConcreteDecoratorB decoratorB = new ConcreteDecoratorB(new ConcreteDecoratorA(component));
        
        decoratorB.operation();
    }
}

 上邊的例子是用最原始的類使用接口實現的，同樣也可以采用抽象類實現，在此不再貼代碼了,測試類的大致代碼走向，即實際的裝飾流程

 

---

裝飾器模式的優缺點：

優點：

1.相比與靜態的繼承，裝飾器模式正如它定義的，那樣可以動態的給一個對象添加額外的職責, 顯得更加靈活。靜態繼承的情況下，如果要添加其他的功能就需要添加新的子類實現功能，然后相互之間繼承，以達到一個組合的功能，對於每一個要添加的功能都要，新建類，顯得特別麻煩，也使得系統越來越復雜，而對於裝飾器來說，為一個特定的Component提供多種不同的Decorator，對於一些要達成的功能，相互組合就可以達成目的

2.裝飾類和被裝飾類可以獨立發展，而不會相互耦合

3.裝飾模式是繼承關系的一個替代方案。我們看裝飾類Decorator，不管裝飾多少層，返回的對象還是Component，實現的還是is-a的關系

缺點：

對於裝飾模式記住一點就足夠了：多層的裝飾是比較復雜的。為什么會復雜呢？你想想看，就像剝洋蔥一樣，你剝到了最后才發現是最里層的裝飾出現了問題，想象一下工作量吧，因此，盡量減少裝飾類的數量，以便降低系統的復雜度

---

與裝飾難解難分的I/O系統