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系统