定义
装饰器模式又名包装(Wrapper)模式。装饰器模式以对客户端透明的方式拓展对象的功能，是继承关系的一种替代方案。
装饰器模式的结构
装饰器模式以对客户透明的方式动态的给一个对象附加上更多的责任。换言之，客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰器模式可以在不是用创造更多子类的情况下，将对象的功能加以拓展。
装饰器模式的类图如下：
装饰器模式的类图
在装饰器模式中的角色有：
抽象构件(Component)角色：给出一个抽象接口，已规范准备接收附加责任的对象。
具体构件(ConcreteComponent)角色：定义一个将要接收附加责任的类
装饰(Decorator)角色：持有一个构件(Component)对象的实例，并定义一个与抽象构件接口一致的接口。
具体装饰(ConcreteDecorator)角色：负责给构件对象“贴上”附加的责任。
示例代码
抽象构件角色
public interface Component {
public void sampleOpreation();
}
具体构件角色：
public class ConcreteComponent implements Component {
@Override
public void sampleOpreation() {
// TODO 完成相关的业务代码
}
}
装饰角色
public class Decorator implements Component {
private Component component;
public Decorator(Component component) {
this.component = component;
}
@Override
public void sampleOpreation() {
//委派给构件
component.sampleOpreation();
}
}
具体装饰角色
public class ConcreteDecoratorA extends Decorator {
public ConcreteDecoratorA(Component component) {
super(component);
}
@Override
public void sampleOpreation() {
super.sampleOpreation();
//TODO 完成相关的业务代码
}
}
public class ConcreteDecoratorB extends Decorator {
public ConcreteDecoratorB(Component component) {
super(component);
}
@Override
public void sampleOpreation() {
super.sampleOpreation();
//TODO 完成相关的业务代码
}
}
齐天大圣的例子
孙悟空有七十二般变化，他的没一种变化都给他带来一种附加的本领。他变成鱼儿时，就已到水里游泳；他变成鸟儿时，就可以在天上飞行。
本例中，Component的角色便是由大名鼎鼎的齐天大圣扮演；ConcreteComponent的角色属于大圣的本尊，就是猢狲本人；Decorator的角色由大圣的七十二变扮演。而ConcreteDecorator的角色就是鱼儿、鸟儿等七十二般变化。
齐天大圣和七十二变的关系
示例代码
抽象构件角色“齐天大圣”接口，定义了一个move()方法，这是所有的具体构建类和装饰类必须实现的。
public interface TheGreatestSage {
public void move();
}
具体构件角色“大圣本尊”，猢狲类
public class Monkey implements TheGreatestSage {
@Override
public void move() {
System.out.println("Monkey move");
}
}
抽象装饰角色“七十二变”
public class Change implements TheGreatestSage {
private TheGreatestSage sage;
public Change(TheGreatestSage sage) {
this.sage = sage;
}
@Override
public void move() {
this.sage.move();
}
}
具体装饰角色，“鱼儿”和“鸟儿”
public class Fish extends Change {
public Fish(TheGreatestSage sage) {
super(sage);
}
@Override
public void move() {
super.move();
System.out.println("Change fish move");
}
}
public class Bird extends Change {
public Bird(TheGreatestSage sage) {
super(sage);
}
@Override
public void move() {
super.move();
System.out.println("Change bird move");
}
}
客户端类
public class Client {
public static void main(String[] args) {
TheGreatestSage sage = new Monkey();
//第一种写法
TheGreatestSage bird = new Bird(sage);
bird.move();
//第二种写法
TheGreatestSage fish = new Fish(new Bird(sage));
fish.move();
}
}
大圣本尊是ConcreteComponent类，而“鸟儿”、“鱼儿”是装饰类，要装饰的是大圣本尊，也就是猢狲类实例。
上面的例子中，系统把大圣从一直猢狲装饰成一只鸟儿(把鸟儿的功能加到了猢狲身上)，然后又把鸟儿装饰成一条鱼儿(把鱼儿的功能装饰到猢狲+鸟儿身上)，从而得到最终呈现猢狲+鸟儿+鱼儿的结果。
大圣装饰过程
如上图所示，大圣的变化首先将鸟儿的功能附加到猢狲身上，然后又将鱼儿的功能附加到猢狲+鸟儿身上。
装饰模式的简化
大多数情况下，装饰模式的实现都要比上面的示意性例子要简单。
如果只有一个ConcreteComponent类，那么可以考虑去掉抽象的Component类(接口)，把Decorator作为一个ConcreteComponent的子类。如下图所示：
合并抽象构件和具体构件
如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。甚至在只有两个ConcreteDecorator类的情况下，都可以这样做，如下图所示：
合并装饰构件和具体装饰构件
透明性的要求
装饰模式对客户端的透明性要求程序不要声明给一个ConcreteComponent类型的变量，而应当声明一个Component类型的变量。
用孙悟空的例子来说，必须永远把孙悟空的所有变化都当成孙悟空来对待，而如果吧孙悟空变成的鱼儿当成鱼儿，而不是孙悟空，那么就被孙悟空骗了，而这是不应当发生的。下面的做法是对的。
TheGreatestSage sage = new Monkey();
TheGreatestSage bird = new Bird(sage);
而下面的做法是不对的：
Monkey sage = new Monkey();
Bird bird = new Bird(sage);
半透明的装饰模式
然而，纯粹的装饰模式很难找到。装饰模式的用意是在不改变接口的前提下，增强所考虑的类的性能。在增强性能的时候，往往要建立新的公开的方法。即便是在孙大圣的系统里，也需要新的方法。比如齐天大圣并没有飞行的能力，而鸟儿有。这就意味着鸟儿应该有一个新的fly()方法。再比如，齐天大圣并没有游泳的能力，而鱼儿有，着就意味着鱼儿应该有一个新的swim()方法。
这就导致了大多数的装饰模式的实现都是“半透明”的，而不是完全透明的。换而言之，允许装饰模式改变接口，增加新的方法。这意味着客户端可以声明ConcreteDecorator类型的变量，从而可以调用ConcreteDecorator类中才有的方法：
TheGreatestSage sage = new Monkey();
Bird bird = new Bird(sage);
bird.fly();
半透明的装饰模式是介于装饰模式和适配器模式之间的。适配器模式的用意是改变所考虑的类的接口，也可以通过改写一个或几个方法，或增加新的方法来增强或改变所考虑的类的功能。大多数的装饰模式实际上是半透明的装饰模式，这样的装饰模式也称作半装饰、半适配器模式。
装饰模式的优点
装饰模式与继承关系的目的都是要拓展对象的功能，但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”一个需要的“装饰”，或者“除掉”一个不需要的“装饰”。继承关系则不同，继承关系是静态的，它在系统运行前就决定了。
通过不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出更多不同行为的组合。
装饰模式的缺点
由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另外一方面，使用装饰模式会产生比使用继承关系所产生的更多的对象。而更多的对象会使得查找错误更为困难，特别是这些对象在看上去极为相似的时候。
装饰设计模式在JAVA I/O库中的应用
装饰模式在Java语言中最著名的应用莫过于JAVA I/O标准库的设计了。
�由于JAVA I/O库需要很多性能的各种组合，如果这些性能都是用继承的方法实现的，那么每一种组合都需要一种类，这样就会造成大量性能重复的类出现。而如果采用装饰模式，那么类的数目就会大大减少，性能的重复也可以减至最小。因此装饰模式是JAVA I/O�库的基本模式。
JAVA I/O库的对象结构如下图，由于JAVA I/O库的对象众多，因此只画出InputStream的部分。
InputStream结构图
根据上图可以看出：
抽象构建角色(Component)：由InputStream扮演。这是一个抽象类，为各种子类型提供统一的接口。
具体构件角色(ConcreteComponent)：由ByteArrayInputStream、FileInputStream、StringBufferInputStream等类扮演。它们实现了抽象构件角色所规定的接口。
抽象装饰角色(Decorator)：由FilterInputStream、ObectInputStream等类扮演。它们实现了InputStream所规定的接口。
具体装饰角色(ConcreteDecorator)：由几个类扮演，分别是BufferedInputStream、DataInputStream以及两个不常用到的类LineNumberInputStream、PushbackInputStream。
半透明的装饰模式
装饰模式和适配器模式都是“包装模式(Wrapper Pattern)”，它们都是通过封装其他的对象达到设计的目的的，但是它们的形态有很多区别。
理想的装饰模式在对被装饰的对象进行功能增强的同时，要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。而适配器模式则不然，一般而言，适配器模式并不要求对源对象的功能进行增强，但是会改变源对象的接口，以便和目标接口相吻合。
装饰模式有透明和半透明两种，这两种的区别就在与装饰角色的接口与抽象构件角色的接口是否完全一致。透明的装饰模式也就时理想的装饰模式，要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。相反，如果装饰角色的接口与抽象构件角色的接口不一致，也就说明装饰角色的接口比抽象构件角色的接口宽的话，装饰角色实际上已经成为了一个适配器角色，这种装饰模式也是可以接受的，称为“半透明”的装饰模式，如下图所示：
透明与半透明的装饰模式
在适配器模式里面，适配器模式的接口通常会与目标类的接口重叠，但往往并不完全相同。换句话说，适配类的接口会比被适配的目标类接口宽。
显然，半透明的装饰模式实际上处于适配器模式与装饰模式之间的灰色地带。如果装饰模式和适配器模式合并称为一个“包装模式”的话，那么半透明的装饰模式倒是可以成为这种合并后的“包装模式“的代表。
InputStream类型中的装饰模式
InputStream类型中的装饰模式是半透明的。为了说明这一点，不妨看一看装饰模式的抽象构建角色InputStream抽象类的源代码。这个抽象类声明了九个方法，并给出了其中八个的实现，另外一个是抽象方法，需要子类实现。
public abstract class InputStream implements Closeable {
public abstract int read() throws IOException;
public int read(byte b[]) throws IOException {
return read(b, 0, b.length);
}
public int read(byte b[], int off, int len) throws IOException {
//……
}
public long skip(long n) throws IOException {
//……
}
public int available() throws IOException {
//……
}
public void close() throws IOException {}
public synchronized void mark(int readlimit) {}
public synchronized void reset() throws IOException {
throw new IOException("mark/reset not supported");
}
public boolean markSupported() {
return false;
}
}
下面是作为装饰模式的抽象装饰角色FilterInputStream类的源代码。可以看出，FilterInputStream的接口与InputStream的接口是完全一致的，也就是说，直到这一步，还是与装饰模式相吻合的。
public class FilterInputStream extends InputStream {
public int read() throws IOException {
return in.read();
}
public int read(byte b[]) throws IOException {
return read(b, 0, b.length);
}
public int read(byte b[]) throws IOException {
return read(b, 0, b.length);
}
public long skip(long n) throws IOException {
return in.skip(n);
}
public int available() throws IOException {
return in.available();
}
public void close() throws IOException {
in.close();
}
public synchronized void mark(int readlimit) {
in.mark(readlimit);
}
public synchronized void reset() throws IOException {
in.reset();
}
public boolean markSupported() {
return in.markSupported();
}
}
下面是具体装饰角色PushbackInputStream的源代码：
public class PushbackInputStream extends FilterInputStream {
private void ensureOpen() throws IOException {
if (in == null)
throw new IOException("Stream closed");
}
public int read() throws IOException {
//……
}
public int read(byte[] b, int off, int len) throws IOException {
//……
}
public void unread(int b) throws IOException {
//……
}
public void unread(byte[] b, int off, int len) throws IOException {
//……
}
public void unread(byte[] b) throws IOException {
unread(b, 0, b.length);
}
public int available() throws IOException {
//……
}
public long skip(long n) throws IOException {
//……
}
public boolean markSupported() {
return false;
}
public synchronized void mark(int readlimit) {
}
public synchronized void reset() throws IOException {
throw new IOException("mark/reset not supported");
}
public synchronized void close() throws IOException {
//……
}
}
通过查看源代码，你会发现，这个装饰类提供了额外的方法unread()，这就意味着PushbackInputStream是一个半透明的装饰类。换句话说，它破坏了理想的装饰模式的要求。如果客户端持有一个类型为InputStream对象的引用in的话，那么如果in的真实类型是PushbackInputStream的话，只要客户端不需要使用unread()方法，那么客户端一般没有问题。但是如果客户端必须使用这个方法，就必须进行向下类型转换。将in的类型转换成为PushbackInputStream之后才可能调用这个方法。但是，这个类型转换意味着客户端必须知道它拿到的引用是指向一个类型为PushbackInputStream的对象。这就破坏了使用装饰模式的原始用意。
现实世界与理论总归是有一段差距的。纯粹的装饰模式在真实的系统中很难找到。一般所遇到的，都是这种半透明的装饰模式。
示例程序
下面是使用I/O流读取文件内容的简单示例
import java.io.BufferedInputStream;
import java.io.DataInputStream;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
public class InputStreamTest {
public static void main(String[] args) {
DataInputStream dis = null;
try {
dis = new DataInputStream(
new BufferedInputStream(
new FileInputStream("23.txt")
)
);
byte[] bytes = new byte[dis.available()];
dis.read(bytes);
String content = new String(bytes);
System.out.println(content);
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
dis.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
观察上面的代码，会发现最里层是一个FileInputStream对象，然后把它传递给一个BufferedInputStream对象，经过BufferedInputStream对象处理后，再将处理后的对象传递给DataInputStream对象进行处理。这个过程，其实就是装饰器的组装过程，FileInputStream对象相当于原始的被装饰的对象，而BufferedInputStream对象和DataInputStream对象则相当于装饰器。
参考
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
