设计模式之Decorator装饰者、Facade外观、Adapter适配器(Java)

装饰者模式

设计模式的基本原则，对内关闭修改。

Decorator Pattern，装饰者模式，也叫包装器模式(Wrapper Pattern)：将一个对象包装起来，增加新的行为和责任。一定是从外部传入，并且可以没有顺序，按照代码的实际需求随意挑换顺序。当使用装饰器模式时，通常将原始对象作为一个参数传给装饰者的构造器。注重功能拓展，关注于在一个对象上动态的添加方法，在同一个方法下实现更多的功能。装饰者能够在运行时递归地被构造。

类图
在这里插入图片描述
涉及角色：

Component：被装饰对象基类，定义对象的接口，可以给这些对象动态增加功能；
ConcreteComponent：具体被装饰对象，定义具体的对象，Decorator可以给它增加额外的功能；
Decorator：抽象装饰者类，持有一个指向Component实例（也就是具体被装饰对象）的引用，且定义与Component一致的接口；
ConcreteDecorator：具体装饰者对象，实现抽象装饰者角色，负责为具体构件添加额外功能。

适用场景：

在不影响其他对象的情况下，以动态透明的方式给单个对象添加职责；
处理那些可以撤消的职责；
当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类

OO原则：动态地将责任附加到对象上。想要扩展功能，装饰者提供有别于继承的另一种选择。原有的不能满足现有的需求，对原有的进行增强。

装饰和继承

除了继承，装饰者模式也可以扩展行为。实际上是因为继承的弊端，大师们提出装饰者模式。

继承是面向对象编程中的一种机制，一个类可以继承另一个类的属性和方法。被继承的类称为父类或基类，继承的类称为子类或派生类。

优点

代码重用：子类可重用父类的方法和属性
简单明了：继承关系一目了然，易理解

缺点

耦合性高：子类与父类紧密耦合，修改父类可能会影响所有子类
灵活性低：继承是静态的，不能在运行时改变
违背单一职责原则：子类往往会继承父类的所有功能，可能导致类职责过多

总结

装饰者模式提供一种动态组合对象行为的方法，灵活性更高，遵循开闭和单一职责原则，但会增加复杂性
继承提供一种静态的代码重用机制，简单明了，但耦合性高，灵活性低

选择哪种模式取决于具体需求：如果需要动态扩展对象行为，使用装饰者模式；如果希望简单地重用代码，使用继承。

实例

Java IO

BufferedInputStream
BufferedOutputStream
BufferedReader
BufferedWriter

当使用InputStream读取数据时，每次可能都会进行实际的IO操作，而BufferedInputStream会先将一部分数据读入缓冲区，后续的读取操作可以直接从缓冲区获取，减少IO次数。

BufferedInputStream并没有改变FileInputStream的基本结构和接口，只是为其添加缓冲特性。

Spring

Spring中的装饰者在类名上有两种表现：

类名中含有Wrapper
类名中含有Decorator

TransactionAwareCacheDecorator：实现Cache接口

外观模式

Facade，外观模式的定义：提供一个统一的高层接口，用来访问子系统中的一批接口，让子系统更容易使用。
在这里插入图片描述

当需要简化并统一一批接口时，考虑使用外观模式，依托于子系统执行。注重多个类的集成、统一适配。通过外观的封装，使应用程序只能看到外观对象，而不会看到具体的细节对象，降低应用程序的复杂度，提高可维护性。

该模式把一些复杂的流程封装成一个简单接口供外部用户使用，涉及3个角色：

门面角色：外观模式的核心。它被客户角色调用，它熟悉子系统的功能。内部根据客户角色的需求预定几种功能的组合。
子系统角色：实现子系统的功能。它对客户角色和Facade时未知的。它内部可以有系统内的相互交互，也可以由供外界调用的接口。
客户角色：通过调用Facede来完成要实现的功能。

优点：

解耦合：客户端和子系统解耦，让子系统内部的模块功能更容易扩展和维护；
易用性：客户端不需要知道子系统内部实现或构成，只需要跟Facade类交互；
层次性：有些方法是对系统外的，有些方法是系统内部相互交互的使用的。子系统把那些暴露给外部的功能集中到Facade类中，这样就可以实现客户端的使用，很好的隐藏子系统内部的细节。

满足的设计原则：莫忒耳原则，又称最少知识原则。

缺点（局限性）：

对子系统的所有操作都交给Facade类来处理，受到Facade类的约束；比如Facade类里可能没有对某个子系统单独的操作，如果需要，则新增方法；
这样可能会导致更多的包装对象被制造出来，以处理和其他组件的沟通，可能会导致复杂度和开发时间的增加，降低运行时性能。

实例

SLF4J，参考Java日志框架SLF4J。

Spring
MeterFacade用于APM系统中的Metric监控，有3个子接口：CounterFacade、TimerFacade、GaugeFacade
在这里插入图片描述

Tomcat
RequestFacade：Request到HttpServletRequest封装
ResponseFacade：Request到HttpServletResponse封装
StandardWrapperFacade：StandardWrapper到ServletConfig封装
ApplicationContextFacade：ApplicationContext到ServletContext封装

适配器

Adapter，适配器允许通常因为接口不兼容而不能在一起工作的类工作在一起，做法是将类自己的接口包裹在一个已存在的类中。将一个对象包装起来改变接口，注重接口兼容，匹配新接口，适配类持有新的目标对象。

适配器模式有三种形式：

对象适配器：通过组合满足用户期待接口，还降低代码间的不良耦合。推荐使用；适配器与适配者之间是关联（？）关系；
类适配器：当客户在接口中定义期望的行为时，就可以应用适配器模式，提供一个实现该接口的类，并且扩展已有的类，通过创建子类来实现适配；适配器与适配者之间是继承关系；
缺省适配器模式：Default Adapter Pattern，又称为单接口适配器模式，是类适配器模式的变体。当不需要实现一个接口所提供的所有方法时，可先设计一个抽象类实现该接口，并为接口中每个方法提供一个默认实现，那么该抽象类的子类可以选择性地覆盖父类的某些方法来实现需求。

涉及角色：

Target：目标类，客户需要的接口。注意：由于这里讨论的是类适配器模式，因此目标不可以是类；
Adaptee：适配者类，是被适配的角色，已存在且无法被修改，因此需要被适配，一般无法获取该类的源代码；
Adapter：适配器类，核心类，将Adaptee和Target进行适配，即把Adaptee类转换成目标类。

优点：

解耦：将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，无须修改原有结构；
复用：适配者在原有系统中可正常使用，在目标类中可充当新角色；
扩展：可通过配置文件很方便地更换适配器，也可在不修改原有代码的基础上增加新适配器，符合开闭原则。

对象适配器模式还有如下优点：

一个对象适配器可以把多个不同的适配者适配到同一个目标；
由于适配器和适配者之间是关联关系，因此可以适配一个适配者的子类，符合里氏代换原则。

缺点：

Java不支持多继承，一个适配器只能适配一个适配者；
适配者类不能为final类；
类适配器模式中的目标类只能为接口，不能为类。

对象适配器模式的缺点：当需要置换适配者类的某些方法时，需要把适配者的子类当做真正的适配者，实现过程较为复杂。

适用场景：

系统需要使用现有的类，而这些类的接口不符合系统的接口；
想要建立一个可重用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作；
两个类所做的事情相同或相似，但具有不同接口时；
旧的系统开发的类已经实现一些功能，但客户端却只能以别的接口的形式访问，但不希望手动更改原有类时；
使用第三方组件，组件接口定义和自己定义的不同，不希望修改自己的接口，但是要使用第三方组件接口的功能。

实例

JDK

Java IO中，如：InputStreamReader、StringReader、OutputStreamWriter、ByteArrayInputStream等。InputStreamReader是一个适配器，Reader是适配者，InputStream是目标。ByteArrayInputStream和OutputStreamWriter同理。

使用IDEA自带的Diagrams插件查看类的依赖关系，注意要勾选Show Dependencies按钮：
在这里插入图片描述
StringReader是适配器，Reader是适配者，String是目标。

Spring

Spring AOP，AdvisorAdapter接口：

public interface AdvisorAdapter {
	boolean supportsAdvice(Advice advice);
	MethodInterceptor getInterceptor(Advisor advisor);
}

Advisor链需要的是MethodInterceptor（拦截器）对象，所以每一个Advisor中的Advice都要适配成对应的MethodInterceptor对象。

其实现类有3个：
在这里插入图片描述
HandlerAdapter
Spring MVC核心组件。

SourcePollingChannelAdapter

比较

适配器模式和装饰者模式

相同点：

都是结构型设计模式，都使用组合思想，即通过将一个对象传递给另一个对象来实现功能的扩展或转换；
两者都不会修改原有类的代码，只是通过增加新的类来实现新的功能。

不同点：

目的：
- 适配器模式旨在解决接口不兼容的问题，使现有类可以与其他类协同工作；
- 装饰者模式则是为了动态地扩展对象的功能，而不改变其结构。
实现方式：
- 适配器模式通常涉及两个不兼容接口的转换，适配器本身只实现接口兼容，不增加新的行为；
- 装饰者模式不改变原对象接口，通过组合和方法包装来添加新行为。
适用场景：
- 期望复用的已有的类，与新系统不兼容时，可考虑使用适配器模式；
- 期望可以动态地为对象添加额外的功能，且功能可随时开启或关闭时，可考虑使用装饰者模式。

以Java IO流举例：

将一个类适配到另一个类，InputStreamReader将Reader类适配到InputStream，实现字节流到字符流的准换；
FilterInputStream继承InputStream，BufferedInputStream继承自FilterInputStream，是具体的装饰器实现者，将InputStream读取的内容保存在内存中，而提高读取性能。

外观模式和装饰者模式

相同点：都是结构型设计模式，都通过组合来实现其功能，装饰者模式侧重于增强对象的功能，而外观模式侧重于简化系统接口。

不同点：

目的：
- 装饰者模式的目的是通过包装对象来动态扩展其功能；
- 外观模式的目的是通过提供一个简化的接口来隐藏系统复杂性。
实现方式：
- 装饰者模式在同一个接口层次上通过递归组合的方式增加行为；
- 外观模式通过创建一个高层接口来简化对复杂子系统的访问。
使用场景：
- 装饰者模式适用于需要动态扩展对象功能的场景；
- 外观模式适用于通过封装来简化与复杂子系统交互的场景。

代理模式和装饰者模式

与原对象实现同一个接口，必须要实现原接口和持有真实的对象，才能称之为代理类。代理模式一定是自身持有这个对象，不需要从外部传入。用代理模式，代理类可以对它的客户隐藏一个对象的具体信息。当使用代理模式时，常常在一个代理类中创建一个对象的实例。注重隔离限制，关注于控制对对象的访问，让外部不能访问你实际的调用对象，如权限控制。代理和真实对象之间的关系通常在编译时就已经确定。