设计模式（三）结构型模式（三）装饰模式、门面模式
写在前面：
- 你好，欢迎你的阅读！
- 我热爱技术，热爱分享，热爱生活， 我始终相信：技术是开源的，知识是共享的！
- 博客里面的内容大部分均为原创，是自己日常的学习记录和总结，便于自己在后面的时间里回顾，当然也是希望可以分享自己的知识。目前的内容几乎是基础知识和技术入门，如果你觉得还可以的话不妨关注一下，我们共同进步！
- 除了分享博客之外，也喜欢看书，写一点日常杂文和心情分享，如果你感兴趣，也可以关注关注！
- 微信公众号：傲骄鹿先生
四、装饰模式（Decorator Pattern）
4.1概述
1、什么是装饰模式
装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。和代理模式很相似，但在对被装饰的对象的控制程度是不同的；装饰者模式是对对象功能的加强，而代理模式是对对象施加控制，并不提供对对象本身功能的加强。
2、为什么要使用装饰模式
通过继承的方式可以使子类具有父类的属性和方法。子类继承父类后，因为一些业务需求可以通过重写的方式来加强父类的方法的一些功能，也可以重新定义某些属性，即覆盖父类的原有属性和方法，使其获得与父类不同的功能。而装饰者模式的最基本的功能就是对传入的一个对象进行功能的加强与优化。那么问题来了，既然继承方式也可以对已有类或对象进行加强，那为什么还要衍生出装饰者模式这一思想呢？
装饰者模式的意图定义为：动态地给一个对象添加一些额外的职责。装饰者模式存在的更重要的意义就在于动态的为对象添加一些功能（或分配额外职责）。一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。在不想增加很多子类的情况下扩展类，如何实现呢？这时就要装饰者模式了。Java中的IO机制就用到了装饰者模式。比如最常用的语句：
BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(filepath)));
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));这就是最常见的装饰者模式了，通过BufferedReader对已有对象FileReader的功能进行加强和优化。其实它不仅可以加强FileReader，所有的字符输入流都可以通过这种方式进行包装。
将所有的字符输入流抽象出了一个基类或接口即Reader,然后通过构造方法的形式将Reader传递给BufferedReader，此时BufferedReader就可以对所有的字符输入流进行拦截和优化了。
如果采用继承机制，每个XXXReader就要衍生出一个BufferedXXXReader，再加上字符输出流和字节输入输出流，那么Java的IO体系结构该是多么的臃肿不堪啊！而装饰者模式的出现解决了这个问题，并且，装饰者的出现也再一次的证明了面向对象的设计原则：多用组合，少用继承！对扩展开放，对修改关闭！
4.2、模式结构
装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任。换言之，客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不使用创造更多子类的情况下，将对象的功能加以扩展。
装饰模式的类图如下：
在装饰模式中的角色有：
●抽象构件(Component)角色：给出一个抽象接口，以规范准备接收附加责任的对象。
●具体构件(ConcreteComponent)角色：定义一个将要接收附加责任的类。
●装饰(Decorator)角色：持有一个构件(Component)对象的实例，并定义一个与抽象构件接口一致的接口。
●具体装饰(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();
// 写相关的业务代码
}
}下面使用齐天大圣的案例进行具体的实现；
孙悟空有七十二般变化，他的每一种变化都给他带来一种附加的本领。他变成鱼儿时，就可以到水里游泳；他变成鸟儿时，就可以在天上飞行。
本例中，Component的角色便由鼎鼎大名的齐天大圣扮演；ConcreteComponent的角色属于大圣的本尊，就是猢狲本人；Decorator的角色由大圣的七十二变扮演。而ConcreteDecorator的角色便是鱼儿、鸟儿等七十二般变化。
（1）抽象构件角色“齐天大圣”接口定义了一个move()方法，这是所有的具体构件类和装饰类必须实现的。
//大圣的尊号
public interface TheGreatestSage {
public void move();
}（2） 具体构件角色“大圣本尊”猢狲类
public class Monkey implements TheGreatestSage {
@Override
public void move() {
//代码
System.out.println("Monkey Move");
}
}（3） 抽象装饰角色“七十二变”
public class Change implements TheGreatestSage {
private TheGreatestSage sage;
public Change(TheGreatestSage sage){
this.sage = sage;
}
@Override
public void move() {
// 代码
sage.move();
}
}（4） 具体装饰角色“鱼儿”
public class Fish extends Change {
public Fish(TheGreatestSage sage) {
super(sage);
}
@Override
public void move() {
// 代码
System.out.println("Fish Move");
}
}（5） 客户端类
public class Client {
public static void main(String[] args) {
TheGreatestSage sage = new Monkey();
// 第一种写法
TheGreatestSage bird = new Bird(sage);
TheGreatestSage fish = new Fish(bird);
// 第二种写法
//TheGreatestSage fish = new Fish(new Bird(sage));
fish.move();
}
}“大圣本尊”是ConcreteComponent类，而“鸟儿”、“鱼儿”是装饰类。要装饰的是“大圣本尊”，也即“猢狲”实例。
上面的例子中，系统把大圣从一只猢狲装饰成了一只鸟儿（把鸟儿的功能加到了猢狲身上），然后又把鸟儿装饰成了一条鱼儿（把鱼儿的功能加到了猢狲+鸟儿身上，得到了猢狲+鸟儿+鱼儿）。
4.3、装饰模式的简化
大多数情况下，装饰模式的实现都要比上面给出的示意性例子要简单。
如果只有一个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();半透明的装饰模式是介于装饰模式和适配器模式之间的。适配器模式的用意是改变所考虑的类的接口，也可以通过改写一个或几个方法，或增加新的方法来增强或改变所考虑的类的功能。大多数的装饰模式实际上是半透明的装饰模式，这样的装饰模式也称做半装饰、半适配器模式。
4.4、优缺点
优点：
（1）装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”一个需要的“装饰”，或者除掉一个不需要的“装饰”。继承关系则不同，继承关系是静态的，它在系统运行前就决定了。
（2）通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。
缺点：
由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。
4.5、设计模式在JAVA中的应用
装饰模式在Java语言中的最著名的应用莫过于Java I/O标准库的设计了。
由于Java I/O库需要很多性能的各种组合，如果这些性能都是用继承的方法实现的，那么每一种组合都需要一个类，这样就会造成大量性能重复的类出现。而如果采用装饰模式，那么类的数目就会大大减少，性能的重复也可以减至最少。因此装饰模式是Java I/O库的基本模式。Java I/O库的对象结构图如下，由于Java I/O的对象众多，因此只画出InputStream的部分。
根据上图可以看出：
●抽象构件(Component)角色：由InputStream扮演。这是一个抽象类，为各种子类型提供统一的接口。
●具体构件(ConcreteComponent)角色：由ByteArrayInputStream、FileInputStream、PipedInputStream、StringBufferInputStream等类扮演。它们实现了抽象构件角色所规定的接口。
●抽象装饰(Decorator)角色：由FilterInputStream扮演。它实现了InputStream所规定的接口。
●具体装饰(ConcreteDecorator)角色：由几个类扮演，分别是BufferedInputStream、DataInputStream以及两个不常用到的类LineNumberInputStream、shbackInputStream。
半透明的装饰模式
装饰模式和适配器模式都是“包装模式(Wrapper Pattern)”，它们都是通过封装其他对象达到设计的目的的，但是它们的形态有很大区别。
理想的装饰模式在对被装饰对象进行功能增强的同时，要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。而适配器模式则不然，一般而言，适配器模式并不要求对源对象的功能进行增强，但是会改变源对象的接口，以便和目标接口相符合。
装饰模式有透明和半透明两种，这两种的区别就在于装饰角色的接口与抽象构件角色的接口是否完全一致。透明的装饰模式也就是理想的装饰模式，要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。相反，如果装饰角色的接口与抽象构件角色接口不一致，也就是说装饰角色的接口比抽象构件角色的接口宽的话，装饰角色实际上已经成了一个适配器角色，这种装饰模式也是可以接受的，称为“半透明”的装饰模式，如下图所示。
在适配器模式里面，适配器类的接口通常会与目标类的接口重叠，但往往并不完全相同。换言之，适配器类的接口会比被装饰的目标类接口宽。显然，半透明的装饰模式实际上就是处于适配器模式与装饰模式之间的灰色地带。如果将装饰模式与适配器模式合并成为一个“包装模式”的话，那么半透明的装饰模式倒可以成为这种合并后的“包装模式”的代表。
InputStream类型中的装饰模式
InputStream类型中的装饰模式是半透明的。为了说明这一点，不妨看一看作装饰模式的抽象构件角色的InputStream的源代码。这个抽象类声明了九个方法，并给出了其中八个的实现，另外一个是抽象方法，需要由子类实现。
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的接口是完全一致的。也就是说，直到这一步，还是与装饰模式相符合的。
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是一个半透明的装饰类。换言 之，它破坏了理想的装饰模式的要求。如果客户端持有一个类型为InputStream对象的引用in的话，那么如果in的真实类型是 PushbackInputStream的话，只要客户端不需要使用unread()方法，那么客户端一般没有问题。但是如果客户端必须使用这个方法，就 必须进行向下类型转换。将in的类型转换成为PushbackInputStream之后才可能调用这个方法。但是，这个类型转换意味着客户端必须知道它 拿到的引用是指向一个类型为PushbackInputStream的对象。这就破坏了使用装饰模式的原始用意。
现实世界与理论总归是有一段差距的。纯粹的装饰模式在真实的系统中很难找到。一般所遇到的，都是这种半透明的装饰模式。
下面是使用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{
dis.close();
}
}
}观察上面的代码，会发现最里层是一个FileInputStream对象，然后把它传递给一个BufferedInputStream对象，经过BufferedInputStream处理，再把处理后的对象传递给了DataInputStream对象进行处理，这个过程其实就是装饰器的组装过程，FileInputStream对象相当于原始的被装饰的对象，而BufferedInputStream对象和DataInputStream对象则相当于装饰器。
五、门面模式
5.1、概述
门面模式是对象的结构模式，外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。
给个网站的导航例子你就懂了：以前我需要在搜索栏逐个搜索网站地址；有了网站导航（用了外观模式）后，就方便很多了
主要作用：
-
实现客户类与子系统类的松耦合
-
降低原有系统的复杂度
-
提高了客户端使用的便捷性，使得客户端无须关心子系统的工作细节，通过外观角色即可调用相关功能。
可以解决的问题：（1）避免了系统与系统之间的高耦合度（2）使得复杂的子系统用法变得简单
5.2、模式原理
1、UML图及组成
2、实例讲解
爷爷已经80岁了，一个人在家生活：每次都需要打开灯、打开电视、打开空调；睡觉时关闭灯、关闭电视、关闭空调；行动不方便，走过去关闭那么多电器很麻烦。代码如下：
电器类：
//灯类
public class SubSystemA_Light {
public void on(){
System.out.println("打开了灯....");
}
public void off(){
System.out.println("关闭了灯....");
}
}
//电视类
public class SubSystemB_Television {
public void on(){
System.out.println("打开了电视....");
}
public void off(){
System.out.println("关闭了电视....");
}
}
//空调类
public class SubSystemC_Aircondition {
public void on(){
System.out.println("打开了电视....");
}
public void off(){
System.out.println("关闭了电视....");
}
} 客户端调用：爷爷使用电器情况
public class Facade Pattern{
public static void main(String[] args){
SubSystemA_Light light = new SubSystemA_Light();
SubSystemB_Television television = new SubSystemB_Television();
SubSystemC_Aircondition aircondition = new SubSystemC_Aircondition();
//起床后开电器
System.out.prinln("起床了")；
light.on();
television.on();
aircondition.on();
System.out.prinln("可以看电视了");
//睡觉时关电器
System.out.prinln("睡觉了");
light.off();
television.off();
aircondition.off();
System.out.prinln("可以睡觉了");
}
}从上面可以看出，在不使用外观模式的情况下，小成爷爷需要对每个电器都进行操作，非常不方便
解决方案：买了一个智能家具控制器（外观对象/统一接口）给他爷爷，他爷爷只需要一键就能打开/关闭 灯、电视机、空调
1、电器类（同上）
2、外观类：智能遥控器
public class Facade{
SubSystemA_Light light；
SubSystemB_Television television ；
SubSystemC_Aircondition aircondition；
//传参
public Facade(SubSystemA_Light light,SubSystemB_Television television,SubSystemC_Aircondition aircondition){
this.light = light;
this.television = television ;
this.aircondition =aircondition;
}
//起床后一键开电器
public void on{
System.out.prinln("起床了")；
light.on();
television.on();
aircondition.on();
}
public void off(){
//睡觉时一键关电器
System.out.prinln("睡觉了")；
light.off()；
television.off();
aircondition.off();
}
}3、客户端调用：爷爷使用智能遥控器的时候
public class Facade Pattern{
public static void main(String[] args){
//实例化电器类
SubSystemA_Light light = new SubSystemA_Light();
SubSystemB_Television television = new SubSystemB_Television();
SubSystemC_Aircondition aircondition = new SubSystemC_Aircondition();
//传参
Facade facade = new Facade(light,television,aircondition);
//客户端直接与外观对象进行交互
facade.on;
System.out.prinln("可以看电视了")；
facade.off;
System.out.prinln("可以睡觉了")；
}
}5.3、优缺点
优点
-
降低了客户类与子系统类的耦合度，实现了子系统与客户之间的松耦合关系
-
外观模式对客户屏蔽了子系统组件，从而简化了接口，减少了客户处理的对象数目并使子系统的使用更加简单。
-
降低原有系统的复杂度和系统中的编译依赖性，并简化了系统在不同平台之间的移植过程
缺点
-
在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”
-
不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
5.4、门面模式在tomcat中的使用
Tomcat中门面模式使用的很多，因为Tomcat中有很多不同组件，每个组件要相互通信，但是又不能将自己内部数据过多的暴露给其他组件。用门面模式隔离数据是个很好的方法。
下面是Request上使用的门面模式：
使用过Servlet的人都清楚，除了要在web.xml做相应的配置外，还需继承一个叫HttpServlet的抽象类，并且重写doGet与doPost方法（当然只重写service方法也是可以的）。
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException {
this.doPost(request, response);
}
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
}
}可以看出doGet与doPost方法有两个参数，参数类型是接口HttpServletRequest与接口HttpServletResponse，那么从Tomcat中传递过来的真实类型到底是什么呢？通过debug会发现，在真正调用TestServlet类之前，会经过很多Tomcat中的方法。如下图所示：
注意红色方框圈中的类，StandardWrapperValue类中的invoke方法225行代码如下：
filterChain.doFilter (request.getRequest(), response.getResponse());在StandardWrapperValue类中并没有直接将Request对象与Response对象传递给ApplicationFilterChain类的doFilter方法，传递的是RequestFacade与ResponseFacade对象，为什么这么说呢，看一下request.getRequest()与response.getResponse()方法就真相大白了。
public HttpServletRequest getRequest() {
if (facade == null) {
facade = new RequestFacade(this);
}
return facade;
}public HttpServletResponse getResponse() {
if (facade == null) {
facade = new ResponseFacade(this);
}
return (facade);
}可以看到它们返回都是各自的一个门面类，那么这样做有什么好处呢？
Request对象中的很多方法都是内部组件之间相互交互时使用的，比如setComet、setRequestedSessionId等方法（这里就不一一列举了）。这些方法并不对外部公开，但是又必须设置为public，因为还需要跟内部组件之间交互使用。最好的解决方法就是通过使用一个Facade类，将与内部组件之间交互使用的方法屏蔽掉，只提供给外部程序感兴趣的方法。
如果不使用Facade类，直接传递的是Request对象和Response对象，那么熟悉容器内部运作的程序员可以分别把ServletRequest和ServletResponse对象向下转换为Request和Response，并调用它们的公共方法。比如拥有Request对象，就可以调用setComet、setRequestedSessionId等方法，这会危害安全性。
