Java IO 装饰者模式
来自： http://www.cnblogs.com/intsmaze/p/5202213.html
装饰模式（Decorator）
装饰模式又名 包装（Wrapper）模式 。
装饰模式以对客户端透明的方式扩展 对象 的功能，是继承关系的一个 替代方案。
装饰模式通过创建一个包装对象，也就是装饰，来包裹真实的对象。
装饰模式以对客户端透明的方式 动态 地给一个对象附加上更多的责任。换言之，客户端并不会觉得对象在装饰前和装饰后有什么不同。
装饰模式可以在不创造更多子类的情况下，将对象的功能加以扩展。
装饰模式把客户端的调用委派到被装饰类。装饰模式的关键在于这种扩展是完全透明的。
装饰模式的角色
抽象构件角色（Component）：给出一个抽象接口，以规范准备接收附加责任的对象。
具体构件角色（Concrete Component）：定义将要接收附加责任的类。
装饰角色（Decorator）：持有一个构件（Component）对象的引用，并定义一个与抽象构件接口一致的接口。
具体装饰角色（Concrete Decorator）：负责给构件对象“贴上”附加的责任。
Java IO中的装饰模式
在IO中，具体构件角色是 节点流 ，装饰角色是 过滤流 。
FilterInputStream和FilterOutputStream是装饰角色，而其他派生自它们的类则是具体装饰角色。
装饰模式的特点
装饰对象和真实对象有相同的接口。这样客户端对象就可以以和真实对象相同的方式和装饰对象交互。
装饰对象包含一个真实对象的引用（reference）。
装饰对象接收所有来自客户端的请求，它把这些请求转发给真实的对象。
装饰对象可以在转发这些请求之前或之后附加一些功能。
这样就确保了在运行时，不用修改给定对象的结构就可以在外部增加附加的功能。
程序实例
doSomething();
}
这是抽象构件角色，是一个接口。具体构件角色实现这个接口：
Component{
@Override
doSomething() {
System.out.println("功能A"
);
}
}
装饰角色：
Component{
Component component;
Decorator(Component component) {
component;
}
@Override
void doSomething() {
component.doSomething();
}
}
其中包含了构件角色的引用，方法调用中利用构件角色的方法。
</div>具体装饰角色（两个）：
Decorator{
ConcreteDecorator1(Component component) {
(component);
}
@Override
.doSomething();
.doAnotherThing();
}
doAnotherThing() {
System.out.println("功能B");
}
}
Decorator{
ConcreteDecorator2(Component component) {
(component);
}
@Override
doSomething() {
.doSomething();
.doAnotherThing();
}
doAnotherThing() {
System.out.println("功能C"
);
}
}
public class Client{
public static void main(String[] args) {
Component component = new ConcreteComponent();
Component component1 = new ConcreteDecorator1(component);
component1.doSomething();
System.out.println("-----------" );
Component component2 = new ConcreteDecorator2(component1);
component2.doSomething();
}
}
问题引入
咖啡店的类设计：
一个饮料基类，各种饮料类继承这个基类，并且计算各自的价钱。
饮料中需要加入各种调料，考虑在基类中加入一些布尔值变量代表是否加入各种调料，基类的cost()中的计算各种调料的价钱，子类覆盖cost()，并且在其中调用超类的cost()，加上特定饮料的价钱，计算出子类特定饮料的价钱。
缺点：类数量爆炸、基类加入的新功能并不适用于所有的子类、调料价钱的改变、新调料的出现都会要求改变现有代码；有的子类并不适合某些调料等情况……
设计原则
类应该对扩展开放，对修改关闭。
我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。
如能实现这样的目标，有什么好处呢？这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。
要让OO设计同时具备开放性和关闭性，不是一件容易的事，通常来说，没有必要把设计的每个部分都这么设计。
遵循开放-关闭原则，通常会引入新的抽象层次，增加代码的复杂度。
我们需要把注意力集中在设计中最有可能改变的地方，然后应用开放-关闭原则。
用装饰者模式解决问题
解决咖啡店饮料问题的方法：
以饮料为主体，然后在运行时以调料来“装饰”饮料。
比如，顾客想要摩卡（Mocha）和奶泡（Whip）深焙咖啡（DarkRoast）：
DarkRoast继承自Beverage，有一个cost()方法。
第一步，以DarkRoast对象开始；
第二步，顾客想要摩卡，所以建立一个Mocha装饰者对象，并用它将DarkRoast对象包装（wrap）起来；
第三步，顾客想要奶泡，所以建立一个Whip装饰者对象，并用它将Mocha对象包起来；（Mocha和Whip也继承自Beverage，有一个cost()方法）；
最后，为顾客算钱，通过调用最外圈装饰者（Whip）的cost()就可以。Whip()的cost()会先委托它装饰的对象（Mocha）计算出价钱，然后在加上奶泡的价钱。Mocha的cost()也是类似。
装饰者模式的特点
装饰者和被装饰对象 有相同的超类型 。
可以用一个或多个装饰者包装一个对象。
因为装饰者和被装饰者具有相同的类型，所以任何需要原始对象的场合，可以用装饰过的对象代替。
装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的。
对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。
装饰者模式的定义
装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
装饰者模式的实现
实现类图如下：
装饰者和被装饰者具有共同的超类，利用继承达到“ 类型匹配 ”，而不是利用继承获得“行为”；将装饰者和被装饰者组合时，加入新的行为。
解决本文中饮料的具体问题时，图中Component即为Beverage（可以是抽象类或者接口），而ConcreteComponent为各种饮 料，Decorator（抽象装饰者）为调料的抽象类或接口，ConcreteDecoratorX则为各种具体的调料。
因为使用对象组合，可以把饮料和调料更有弹性地加以混合与匹配。
代码外部细节：
代码中实现的时候，通过构造函数将被装饰者传入装饰者中即可，如最后的调用形式如下：
Beverage beverage = new DarkRoast();
beverage = new Mocha(beverage);
beverage = new Whip(beverage);
即完成了两层包装，此时再调用beverage的cost()函数即可得到总价。
java.io包内的装饰者模式
装饰者模式的缺点：在设计中加入大量的小类，如果过度使用，会让程序变得复杂。
</div>