java之装饰器模式

java之装饰器模式
Decorator Pattern(装饰器模式)，定义：Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.(动态地给⼀个对象添加⼀些额外的职责。

就增加功能来说，装饰模式相⽐⽣成⼦类更为灵活)
装饰器的通⽤视图：
上图四个⾓⾊解释⼀下：
ponent抽象构件：
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等。

下⾯给出⼀个简单的例⼦：
1package decorator;
2 //抽象构件
3public interface Component
4 {
5void operation();
6 }
7 //具体的抽象构件的实现
8public class ConcreteComponent implements Component
9 {
10
11/** { @inheritDoc } */
12 @Override
13public void operation()
14 {
15 System.out.println("我是ConcreteComponent，是最原始的实现类，我处于最底层");
16 }
17
18 }
19 //抽象装饰器
20public abstract class Decorator implements Component
21 {
22private Component component;
23
24/**
25 * @param component
26*/
27public Decorator(Component component)
28 {
ponent = component;
30 }
31
32/** { @inheritDoc } */
33 @Override
34public void operation()
35 {
36 component.operation();
37 }
38 }
39 //具体装饰器A
40public class ConcreteDecoratorA extends Decorator
41 {
42
43/**
44 * @param component
45*/
46public ConcreteDecoratorA(Component component)
47 {
48super(component);
49 }
50
51public void methodA()
52 {
53 System.out.println("我是ConcreteDecoratorA，添加的新功能");
54 }
55
56/** { @inheritDoc } */
57 @Override
58public void operation()
59 {
60 methodA();
61super.operation();
62 System.out.println("ConcreteDecoratorA的operation执⾏完毕");
63 }
64
65 }
66 //具体装饰器B
67public class ConcreteDecoratorB extends Decorator
68 {
69
70/**
71 * @param component
72*/
73public ConcreteDecoratorB(Component component)
74 {
75super(component);
76 }
77
78public void methodB()
79 {
80 System.out.println("我是ConcreteDecoratorB，添加的新功能");
81 }
82
83/** { @inheritDoc } */
84 @Override
85public void operation()
86 {
87 methodB();
88super.operation();
89 System.out.println("ConcreteDecoratorB的operation执⾏完毕");
90 }
91
92 }
93 //测试类
94public class Demo
95 {
96public 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系统。