【1】适配器模式
① 介绍
适配器模式是将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
适配器的作用可以简单通过下图得知，OO适配器就是将一个接口转换成另一个接口，以符合客户的期望。
实际场景应用可以联想插座适配器，如下图所示。
适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表示，主的目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)
适配器模式属于结构型模式，主要分为三类：类适配器模式、对象适配器模式、接口适配器模式
客户使用适配器的过程如下：
① 客户通过目标接口调用适配器的方法对适配器发出请求；
② 适配器使用被适配者接口把请求转换成被适配者的一个或多个调用接口。用户调用适配器转化出来的目标接口方法，适配器再调用被适配者的相关接口方法
③ 客户接受到调用的结果，但并未察觉这一切是适配器在其转换作用。
也就是说，客户和被适配者是解耦的，一个不知道另一个。如果目标接口很大，那么适配器的工作会很多。
比如SpringMVC中DispatcherServlet、HandlerAdapter与Handler之间的关系。DispatcherServlet只需要调用HandlerAdapter的handle方法即可，剩下的工作交给HandlerAdapter处理，而不关心下游细节。
使用HandlerAdapter 的原因分析:
可以看到处理器的类型不同，有多重实现方式，那么调用方式就不是确定的，如果需要直接调用Controller 方法，需要调用的时候就得不断是使用if else 来进行判断是哪一种子类然后执行。那么如果后面要扩展Controller，就得修改原来的代码，这样违背了OCP 原则。
SpringMVC定义了一个适配器接口，使得每一种Controller有一种对应的适配器实现类。适配器代替controller执行相应的方法。扩展controller时，只需要增加一个适配器类就完成了SpringMVC的扩展。
② UML类图
如下图所示，这个适配器模式充满着良好的OO设计原则：使用对象组合，以修改的接口包括被适配者。这种做法还有额外的优点就是被适配者的任何子类都可以搭配着适配器使用。
需要注意的是，这个模式是如何把客户和接口绑定起来，而不是和实现绑定起来的。我们可以使用数个适配器，每一个都负责转换不同组的后台类。或者，也可以加上新的实现，只要他们遵守模板接口就可以。
③ 对象和类的适配器
实际上有两种适配器：对象适配器和类适配器。类适配器需要多重继承才能实现，这在Java中不可能的。但是当你使用多重继承语言的时候，还是可能遇到这样的需求。
类适配器类图如下
类适配器不是使用组合来适配被适配者，而是继承被适配者和目标类。类适配器的优点是不需要重新实现其整个适配者。必要的时候可以覆盖被适配者的行为。
对象适配器的优点是不仅可以适配某个类，也可以适配该类的任何子类，将工作委托给被适配者进行让事情更有弹性。
④ 真实案例
如这里编写一个EnumeratorIterator适配器，将代码中遗留的枚举转换为Iterator使用。
import java.util.Enumeration; import java.util.Iterator; /** * Created by jianggc at 2021/11/2. */ public class EnumeratorIterator implements Iterator { Enumeration enumeration; public EnumeratorIterator(Enumeration enumeration) { this.enumeration = enumeration; } @Override public boolean hasNext() { return enumeration.hasMoreElements(); } @Override public Object next() { return enumeration.nextElement(); } @Override public void remove() { throw new UnsupportedOperationException(); } }
⑤ 装饰者模式与适配器模式
装饰着模式重点在包装，当事情一旦涉及到装饰着，就表示有一些新的行为或责任要加入到设计中
如mybatis中的CachingExecutor。其拥有目标对象Executor delegate的引用，当执行方法如update时，首先执行装饰者CachingExecutor自身行为 flushCacheIfRequired(ms);，然后再传递调用目标对象delegate的update方法。
@Override public int update(MappedStatement ms, Object parameterObject) throws SQLException { flushCacheIfRequired(ms); return delegate.update(ms, parameterObject); }
适配器模式的重点在转换、解耦。当必须将若干类整合在一起来提供给客户所期望的接口时，不妨试试适配器。
【2】类适配器
基本介绍：Adapter 类，通过继承src 类，实现dst 类接口，完成src->dst 的适配。以生活中充电器的例子来讲解适配器，充电器本身相当于Adapter，220V 交流电相当于src (即被适配者)，我们的目dst(即目标)是5V 直流电。
思路分析如下图
① 代码示例
① 适配接口
//适配接口 public interface IVoltage5V { public int output5V(); }
② 被适配的类
//被适配的类 public class Voltage220V { //输出220V的电压 public int output220V() { int src = 220; System.out.println("电压=" + src + "伏"); return src; } }
③ 适配器
//适配器类 public class VoltageAdapter extends Voltage220V implements IVoltage5V { @Override public int output5V() { // TODO Auto-generated method stub //获取到220V电压 int srcV = output220V(); int dstV = srcV / 44 ; //转成 5v return dstV; } }
④ 客户端
public class Phone { //充电 public void charging(IVoltage5V iVoltage5V) { if(iVoltage5V.output5V() == 5) { System.out.println("电压为5V, 可以充电~~"); } else if (iVoltage5V.output5V() > 5) { System.out.println("电压大于5V, 不能充电~~"); } } } public static void main(String[] args) { System.out.println(" === 类适配器模式 ===="); Phone phone = new Phone(); phone.charging(new VoltageAdapter()); }
② 分析
Java 是单继承机制，所以类适配器需要继承src 类这一点算是一个缺点, 因为这要求dst 必须是接口，有一定局限性。
src 类的方法在Adapter 中都会暴露出来，也增加了使用的成本。
由于其继承了src 类，所以它可以根据需求重写src 类的方法，使得Adapter 的灵活性增强了。
【3】对象适配器模式
基本思路和类的适配器模式相同，只是将Adapter 类作修改，不是继承src 类，而是持有src 类的实例，以解决兼容性的问题。即：持有src 类，实现dst 类接口，完成src->dst 的适配。另外根据“合成复用原则”，在系统中尽量使用关联关系（聚合）来替代继承关系。对象适配器模式是适配器模式常用的一种。
仍然以上述充电案例分析，思路分析如下图：
修改适配器类如下：
//适配器类 public class VoltageAdapter implements IVoltage5V { private Voltage220V voltage220V; // 关联关系-聚合 //通过构造器，传入一个 Voltage220V 实例 public VoltageAdapter(Voltage220V voltage220v) { this.voltage220V = voltage220v; } @Override public int output5V() { int dst = 0; if(null != voltage220V) { int src = voltage220V.output220V();//获取220V 电压 System.out.println("使用对象适配器，进行适配~~"); dst = src / 44; System.out.println("适配完成，输出的电压为=" + dst); } return dst; } }
client如下
public static void main(String[] args) { // TODO Auto-generated method stub System.out.println(" === 对象适配器模式 ===="); Phone phone = new Phone(); phone.charging(new VoltageAdapter(new Voltage220V())); }
分析
对象适配器和类适配器其实算是同一种思想，只不过实现方式不同。根据合成复用原则，使用组合替代继承， 所以它解决了类适配器必须继承src 的局限性问题，也不再要求dst必须是接口。使用成本更低，更灵活。
【4】接口适配器模式
一些书籍称为：适配器模式(Default Adapter Pattern)或缺省适配器模式。核心思路就是当不需要全部实现接口提供的方法时，可先设计一个抽象类实现接口，并为该接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求。
其适用于一个接口不想使用其所有的方法的情况。
如下所示接口有四个方法：
public interface Interface4 { public void m1(); public void m2(); public void m3(); public void m4(); }
在抽象类AbsAdapter 我们将Interface4 的方法进行默认实现。
//在AbsAdapter 我们将 Interface4 的方法进行默认实现 public abstract class AbsAdapter implements Interface4 { //默认实现 public void m1() { } public void m2() { } public void m3() { } public void m4() { } }
client选择覆盖我们需要使用的接口方法，测试如下：
public static void main(String[] args) { AbsAdapter absAdapter = new AbsAdapter() { //只需要去覆盖我们 需要使用 接口方法 @Override public void m1() { System.out.println("使用了m1的方法"); } }; absAdapter.m1(); }
适配器模式的注意事项和细节
三种命名方式，是根据src 是以怎样的形式给到Adapter（在Adapter 里的形式）来命名的。
类适配器：以类给到，在Adapter 里，就是将src 当做类，继承
对象适配器：以对象给到，在Adapter 里，将src 作为一个对象，持有
接口适配器：以接口给到，在Adapter 里，将src 作为一个接口，实现
Adapter 模式最大的作用还是将原本不兼容的接口融合在一起工作。实际开发中，实现起来不拘泥于我们讲解的三种经典形式
【5】外观模式
外观模式提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。外观的意图是要提供一个简单的接口，好让一个子系统更易于使用。
① 如果外观封装了子系统的类，那么需要低层功能的客户如何接触这些类？
外观没有封装子系统的类，外观只提供简化的接口。所以客户如果觉得有必要，依然可以直接使用子系统的类。这是外观模式的一个很友好的特征：提供简化的接口的同时，依然将系统完整的功能暴露出来，以供需要的人使用。
如果需要，可以让外观附加聪明功能，让使用子系统更加方便。当然，也可以根据实际应用，为子系统创建多个外观。
② 外观模式的优点
外观模式不只是简化接口，也允许你将客户实现从任何子系统中解耦。
③ 适配器模式与外观模式
外观和适配器都可以包装许多类。适配器模式将一个或多个类接口变成客户所期望的一个接口。类似地，一个外观也可以只针对一个拥有复杂接口的类提供简化的接口。两种模式的差异不在于它们包装了一个类，而是在于它们的意图。适配器模式的意图是：改变接口符合客户的期望；而外观模式的意图是：提供子系统的一个简化接口。
④ 最少知识(Least Knowledge)原则
外观模式完美契合了最少知识原则，客户只需要知道外观即可， 不需要知道外观如何操作、下游子类细节。
当需要使用一个现有的类而其接口并不符合你的需要时，就使用适配器。当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观。适配器改变接口以符合客户的期望。外观将客户从一个复杂的子系统中解耦。
适配器将一个对象保证起来以改变其接口；装饰者将一个对象包装起来以增加新的行为和责任；而外观将一群对象包装起来以简化其接口。
