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等。

下面给出一个简单的例子:

  1 package decorator;
  2 //抽象构件
  3 public interface Component
  4 {
  5     void operation();
  6 }
  7 //具体的抽象构件的实现
  8 public class ConcreteComponent implements Component
  9 {
 10 
 11     /** { @inheritDoc } */
 12     @Override
 13     public void operation()
 14     {
 15         System.out.println("我是ConcreteComponent,是最原始的实现类,我处于最底层");
 16     }
 17     
 18 }
 19 //抽象装饰器
 20 public abstract class Decorator implements Component
 21 {
 22     private Component component;
 23 
 24     /** 
 25      * @param component 
 26      */ 
 27     public Decorator(Component component)
 28     {
 29         this.component = component;
 30     }
 31     
 32     /** { @inheritDoc } */
 33     @Override
 34     public void operation()
 35     {
 36         component.operation();
 37     }
 38 }
 39 //具体装饰器A
 40 public class ConcreteDecoratorA extends Decorator
 41 {
 42 
 43     /** 
 44      * @param component 
 45      */ 
 46     public ConcreteDecoratorA(Component component)
 47     {
 48         super(component);
 49     }
 50     
 51     public void methodA() 
 52     {
 53         System.out.println("我是ConcreteDecoratorA,添加的新功能");
 54     }
 55     
 56     /** { @inheritDoc } */
 57     @Override
 58     public void operation()
 59     {
 60         methodA();
 61         super.operation();
 62         System.out.println("ConcreteDecoratorA的operation执行完毕");
 63     }
 64 
 65 }
 66 //具体装饰器B
 67 public class ConcreteDecoratorB extends Decorator
 68 {
 69 
 70     /** 
 71      * @param component 
 72      */ 
 73     public ConcreteDecoratorB(Component component)
 74     {
 75         super(component);
 76     }
 77     
 78     public void methodB() 
 79     {
 80         System.out.println("我是ConcreteDecoratorB,添加的新功能");
 81     }
 82     
 83     /** { @inheritDoc } */
 84     @Override
 85     public void operation()
 86     {
 87         methodB();
 88         super.operation();
 89         System.out.println("ConcreteDecoratorB的operation执行完毕");
 90     }
 91 
 92 }
 93 //测试类
 94 public class Demo
 95 {
 96     public static void main(String[] args)
 97     {
 98         Component component = new ConcreteComponent();
 99         
100         ConcreteDecoratorB decoratorB = new ConcreteDecoratorB(new ConcreteDecoratorA(component));
101         
102         decoratorB.operation();
103     }
104 }

 上边的例子是用最原始的类使用接口实现的,同样也可以采用抽象类实现,在此不再贴代码了,测试类的大致代码走向,即实际的装饰流程

 


装饰器模式的优缺点:

优点:

1.相比与静态的继承,装饰器模式正如它定义的,那样可以动态的给一个对象添加额外的职责, 显得更加灵活。静态继承的情况下,如果要添加其他的功能就需要添加新的子类实现功能,然后相互之间继承,以达到一个组合的功能,对于每一个要添加的功能都要,新建类,显得特别麻烦,也使得系统越来越复杂,而对于装饰器来说,为一个特定的Component提供多种不同的Decorator,对于一些要达成的功能,相互组合就可以达成目的

2.装饰类和被装饰类可以独立发展,而不会相互耦合

3.装饰模式是继承关系的一个替代方案。我们看装饰类Decorator,不管装饰多少层,返回的对象还是Component,实现的还是is-a的关系

缺点:

对于装饰模式记住一点就足够了:多层的装饰是比较复杂的。为什么会复杂呢?你想想看,就像剥洋葱一样,你剥到了最后才发现是最里层的装饰出现了问题,想象一下工作量吧,因此,尽量减少装饰类的数量,以便降低系统的复杂度


与装饰难解难分的I/O系统

posted @ 2017-10-01 21:57  朱洪昌  阅读(5396)  评论(0编辑  收藏  举报