java设计模式－装饰器模式(Decorator)

定义

装饰器模式又名包装(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对象则相当于装饰器。

参考

《JAVA与模式》之装饰模式

最后编辑于：2017.12.08 14:37:33

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 206,968评论 6赞 482
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 88,601评论 2赞 382
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 153,220评论 0赞 344
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 55,416评论 1赞 279
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 64,425评论 5赞 374
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 49,144评论 1赞 285
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 38,432评论 3赞 401
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 37,088评论 0赞 261
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 43,586评论 1赞 300
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 36,028评论 2赞 325
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 38,137评论 1赞 334
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 33,783评论 4赞 324
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 39,343评论 3赞 307
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 30,333评论 0赞 19
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 31,559评论 1赞 262
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 45,595评论 2赞 355
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 42,901评论 2赞 345

java设计模式－装饰器模式(Decorator)

定义

装饰器模式的结构

示例代码

齐天大圣的例子

示例代码

装饰模式的简化

透明性的要求

半透明的装饰模式

装饰模式的优点

装饰模式的缺点

装饰设计模式在JAVA I/O库中的应用

半透明的装饰模式

InputStream类型中的装饰模式

示例程序

参考

推荐阅读更多精彩内容