您当前位置：首页 > php开源 > php教程 > 《JAVA与模式》之装饰模式

《JAVA与模式》之装饰模式

来源：程序员人生发布时间：2017-02-24 10:37:55 阅读次数：2878次

学习Java的同学注意了！！！
学习进程中遇到甚么问题或想获得学习资源的话，欢迎加入Java学习交换群，群号码：183993990 我们1起学Java！

在阎宏博士的《JAVA与模式》1书中开头是这样描写装潢（Decorator）模式的：

　　装潢模式又名包装(Wrapper)模式。装潢模式以对客户端透明的方式扩大对象的功能，是继承关系的1个替换方案。

装潢模式的结构

　　装潢模式以对客户透明的方式动态地给1个对象附加上更多的责任。换言之，客户端其实不会觉得对象在装潢前和装潢后有甚么不同。装潢模式可以在不使用创造更多子类的情况下，将对象的功能加以扩大。

　　装潢模式的类图以下：

　　在装潢模式中的角色有：

　　●　　抽象构件(Component)角色：给出1个抽象接口，以规范准备接收附加责任的对象。

　　●　　具体构件(ConcreteComponent)角色：定义1个将要接收附加责任的类。

　　●　　装潢(Decorator)角色：持有1个构件(Component)对象的实例，并定义1个与抽象构件接口1致的接口。

　　●　　具体装潢(ConcreteDecorator)角色：负责给构件对象“贴上”附加的责任。

源代码

　　抽象构件角色

public interface Component { public void sampleOperation();
    
}

　　具体构件角色

public class ConcreteComponent implements Component {

    @Override public void sampleOperation() { // 写相干的业务代码  }

}

　　装潢角色

public class Decorator implements Component{ private Component component; public Decorator(Component component){ this.component = component;
    }

    @Override public void sampleOperation() { // 委派给构件  component.sampleOperation();
    }
    
}

　　具体装潢角色

public class ConcreteDecoratorA extends Decorator { public ConcreteDecoratorA(Component component) { super(component);
    }
    
    @Override public void sampleOperation() {
　　　　　super.sampleOperation(); // 写相干的业务代码  }
}

public class ConcreteDecoratorB extends Decorator { public ConcreteDecoratorB(Component component) { super(component);
    }
    
    @Override public void sampleOperation() {
　　　　 super.sampleOperation(); // 写相干的业务代码  }
}

齐天大圣的例子

　　孙悟空有7102般变化，他的每种变化都给他带来1种附加的本领。他变成鱼儿时，就能够到水里游泳；他变成鸟儿时，就能够在天上飞行。

　　本例中，Component的角色便由鼎鼎大名的齐天大圣扮演；ConcreteComponent的角色属于大圣的本尊，就是猢狲本人；Decorator的角色由大圣的7102变扮演。而ConcreteDecorator的角色便是鱼儿、鸟儿等7102般变化。

源代码

　　抽象构件角色“齐天大圣”接口定义了1个move()方法，这是所有的具体构件类和装潢类必须实现的。

//大圣的尊号 public interface TheGreatestSage { public void move();
}

　　具体构件角色“大圣本尊”猢狲类

public class Monkey implements TheGreatestSage {

    @Override public void move() { //代码 System.out.println("Monkey Move");
    }

}

　　抽象装潢角色“7102变”

public class Change implements TheGreatestSage { private TheGreatestSage sage; public Change(TheGreatestSage sage){ this.sage = sage;
    }
    @Override public void move() { // 代码  sage.move();
    }

}

　　具体装潢角色“鱼儿”

public class Fish extends Change { public Fish(TheGreatestSage sage) { super(sage);
    }

    @Override public void move() { // 代码 System.out.println("Fish Move");
    }
}

　　具体装潢角色“鸟儿”

public class Bird extends Change { public Bird(TheGreatestSage sage) { super(sage);
    }

    @Override public void move() { // 代码 System.out.println("Bird Move");
    }
}

　客户端类

public class Client { public static void main(String[] args) {
        TheGreatestSage sage = new Monkey(); // 第1种写法 TheGreatestSage bird = new Bird(sage);
        TheGreatestSage fish = new Fish(bird); // 第2种写法 //TheGreatestSage fish = new Fish(new Bird(sage));  fish.move(); 
    }

}

　　“大圣本尊”是ConcreteComponent类，而“鸟儿”、“鱼儿”是装潢类。要装潢的是“大圣本尊”，也即“猢狲”实例。

　　上面的例子中，系统把大圣从1只猢狲装潢成了1只鸟儿（把鸟儿的功能加到了猢狲身上），然后又把鸟儿装潢成了1条鱼儿（把鱼儿的功能加到了猢狲+鸟儿身上，得到了猢狲+鸟儿+鱼儿）。

　　如上图所示，大圣的变化首先将鸟儿的功能附加到了猢狲身上，然后又将鱼儿的功能附加到猢狲+鸟儿身上。

装潢模式的简化

　　大多数情况下，装潢模式的实现都要比上面给出的示意性例子要简单。

　　如果只有1个ConcreteComponent类，那末可以斟酌去掉抽象的Component类（接口），把Decorator作为1个ConcreteComponent子类。以下图所示：

　　如果只有1个ConcreteDecorator类，那末就没有必要建立1个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成1个类。乃至在只有两个ConcreteDecorator类的情况下，都可以这样做。以下图所示：

透明性的要求

　　装潢模式对客户真个透明性要求程序不要声明1个ConcreteComponent类型的变量，而应当声明1个Component类型的变量。

　　用孙悟空的例子来讲，必须永久把孙悟空的所有变化都当做孙悟空来对待，而如果把老孙变成的鱼儿当做鱼儿，而不是老孙，那就被老孙骗了，而这时候不应当产生的。下面的做法是对的：

TheGreatestSage sage = new Monkey();
TheGreatestSage bird = new Bird(sage);

　　而下面的做法是不对的：

Monkey sage = new Monkey();
Bird bird = new Bird(sage);

半透明的装潢模式

　　但是，纯洁的装潢模式很难找到。装潢模式的意图是在不改变接口的条件下，增强所斟酌的类的性能。在增强性能的时候，常常需要建立新的公然的方法。即使是在孙大圣的系统里，也需要新的方法。比如齐天大圣类并没有飞行的能力，而鸟儿有。这就意味着鸟儿应当有1个新的fly()方法。再比如，齐天大圣类并没有游泳的能力，而鱼儿有，这就意味着在鱼儿类里应当有1个新的swim()方法。

　　这就致使了大多数的装潢模式的实现都是“半透明”的，而不是完全透明的。换言之，允许装潢模式改变接口，增加新的方法。这意味着客户端可以声明ConcreteDecorator类型的变量，从而可以调用ConcreteDecorator类中才有的方法：

TheGreatestSage sage = new Monkey();
Bird bird = new Bird(sage);
bird.fly();

　　半透明的装潢模式是介于装潢模式和适配器模式之间的。适配器模式的意图是改变所斟酌的类的接口，也能够通过改写1个或几个方法，或增加新的方法来增强或改变所斟酌的类的功能。大多数的装潢模式实际上是半透明的装潢模式，这样的装潢模式也称做半装潢、半适配器模式。

装潢模式的优点

　　（1）装潢模式与继承关系的目的都是要扩大对象的功能，但是装潢模式可以提供比继承更多的灵活性。装潢模式允许系统动态决定“贴上”1个需要的“装潢”，或除掉1个不需要的“装潢”。继承关系则不同，继承关系是静态的，它在系统运行前就决定了。

　　（2）通过使用不同的具体装潢类和这些装潢类的排列组合，设计师可以创造出很多不同行动的组合。

装潢模式的缺点

　　由于使用装潢模式，可以比使用继承关系需要较少数目的类。使用较少的类，固然使设计比较易于进行。但是，在另外一方面，使用装潢模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。

设计模式在JAVA I/O库中的利用

　　装潢模式在Java语言中的最著名的利用莫过于Java I/O标准库的设计了。

　　由于Java I/O库需要很多性能的各种组合，如果这些性能都是用继承的方法实现的，那末每种组合都需要1个类，这样就会造成大量性能重复的类出现。而如果采取装潢模式，那末类的数目就会大大减少，性能的重复也能够减至最少。因此装潢模式是Java I/O库的基本模式。

　　Java I/O库的对象结构图以下，由于Java I/O的对象众多，因此只画出InputStream的部份。

　　根据上图可以看出：

　　●　　抽象构件(Component)角色：由InputStream扮演。这是1个抽象类，为各种子类型提供统1的接口。

　　●　　具体构件(ConcreteComponent)角色：由ByteArrayInputStream、FileInputStream、PipedInputStream、StringBufferInputStream等类扮演。它们实现了抽象构件角色所规定的接口。

　　●　　抽象装潢(Decorator)角色：由FilterInputStream扮演。它实现了InputStream所规定的接口。

　　●　　具体装潢(ConcreteDecorator)角色：由几个类扮演，分别是BufferedInputStream、DataInputStream和两个不经常使用到的类LineNumberInputStream、PushbackInputStream。

半透明的装潢模式

　　装潢模式和适配器模式都是“包装模式(Wrapper Pattern)”，它们都是通过封装其他对象到达设计的目的的，但是它们的形态有很大区分。

　　理想的装潢模式在对被装潢对象进行功能增强的同时，要求具体构件角色、装潢角色的接口与抽象构件角色的接口完全1致。而适配器模式则不然，1般而言，适配器模式其实不要求对源对象的功能进行增强，但是会改变源对象的接口，以便和目标接口符合合。

　　装潢模式有透明和半透明两种，这两种的区分就在于装潢角色的接口与抽象构件角色的接口是不是完全1致。透明的装潢模式也就是理想的装潢模式，要求具体构件角色、装潢角色的接口与抽象构件角色的接口完全1致。相反，如果装潢角色的接口与抽象构件角色接口不1致，也就是说装潢角色的接口比抽象构件角色的接口宽的话，装潢角色实际上已成了1个适配器角色，这类装潢模式也是可以接受的，称为“半透明”的装潢模式，以下图所示。

　　在适配器模式里面，适配器类的接口通常会与目标类的接口堆叠，但常常其实不完全相同。换言之，适配器类的接口会比被装潢的目标类接口宽。

　　明显，半透明的装潢模式实际上就是处于适配器模式与装潢模式之间的灰色地带。如果将装潢模式与适配器模式合并成为1个“包装模式”的话，那末半透明的装潢模式倒可以成为这类合并后的“包装模式”的代表。

InputStream类型中的装潢模式

　　InputStream类型中的装潢模式是半透明的。为了说明这1点，无妨看1看做装潢模式的抽象构件角色的InputStream的源代码。这个抽象类声明了9个方法，并给出了其中8个的实现，另外1个是抽象方法，需要由子类实现。

public abstract class InputStream implements Closeable { public abstract int read() throws IOException; public int read(byte b[]) throws IOException {} 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 {} public boolean markSupported() {}

}

　　下面是作为装潢模式的抽象装潢角色FilterInputStream类的源代码。可以看出，FilterInputStream的接口与InputStream的接口是完全1致的。也就是说，直到这1步，还是与装潢模式符合合的。

public class FilterInputStream extends InputStream { protected FilterInputStream(InputStream in) {} public int read() throws IOException {} public int read(byte b[]) throws IOException {} 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 {} public boolean markSupported() {}
}

　　下面是具体装潢角色PushbackInputStream的源代码。

public class PushbackInputStream extends FilterInputStream { private void ensureOpen() throws IOException {} public PushbackInputStream(InputStream in, int size) {} public PushbackInputStream(InputStream in) {} 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 {} public int available() throws IOException {} public long skip(long n) throws IOException {} public boolean markSupported() {} public synchronized void mark(int readlimit) {} public synchronized void reset() throws IOException {} public synchronized void close() throws IOException {}
}

　　查看源码，你会发现，这个装潢类提供了额外的方法unread()，这就意味着PushbackInputStream是1个半透明的装潢类。换言之，它破坏了理想的装潢模式的要求。如果客户端持有1个类型为InputStream对象的援用in的话，那末如果in的真实类型是 PushbackInputStream的话，只要客户端不需要使用unread()方法，那末客户端1般没有问题。但是如果客户端必须使用这个方法，就必须进行向下类型转换。将in的类型转换成为PushbackInputStream以后才可能调用这个方法。但是，这个类型转换意味着客户端必须知道它拿到的援用是指向1个类型为PushbackInputStream的对象。这就破坏了使用装潢模式的原始意图。

　　现实世界与理论总归是有1段差距的。纯洁的装潢模式在真实的系统中很难找到。1般所遇到的，都是这类半透明的装潢模式。

　　下面是使用I/O流读取文件内容的简单操作示例。

public class IOTest { public static void main(String[] args) throws IOException { // 流式读取文件 DataInputStream dis = null; try{
            dis = new DataInputStream( new BufferedInputStream( new FileInputStream("test.txt")
                    )
            ); //读取文件内容 byte[] bs = new byte[dis.available()];
            dis.read(bs);
            String content = new String(bs);
            System.out.println(content);
        }finally{

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠
程序员人生

------分隔线----------------------------

上一篇 mysql进阶(三十)MySQL Workbench出错KERNELBASE.dll停止工作 + MySQL服务消失 + 服务启动失败解决方法

下一篇 TensorFlow入门和示例分析

分享到:

------分隔线----------------------------

为你装逼为你疯

积分：2787

7粉丝

12关注

栏目热点