- 前面一篇文章讲了设计模式中的创建型模式。创建型模式主要解决对象的创建问题，封装复杂的创建过程，解耦对象的创建代码和使用代码。
- 其中，单例模式用来创建全局唯一的对象。工厂模式用来创建不同但是相关类型的对象（继承同一父类或者接口的一组子类），由给定的参数来决定创建哪种类型的对象。建造者模式是用来创建复杂对象，可以通过设置不同的可选参数，“定制化”地创建不同的对象。原型模式针对创建成本比较大的对象，利用对已有对象进行复制的方式进行创建，以达到节省创建时间的目的。
- 接下来讲另外一种类型的设计模式：结构型模式。结构型模式主要总结了一些类或对象组合在一起的经典结构，这些经典的结构可以解决特定应用场景的问题。结构型模式包括：代理模式、桥接模式、装饰器模式、适配器模式、门面模式、组合模式、享元模式。
- 代理模式有不同的形式, 主要有三种 静态代理、动态代理 (JDK 代理、接口代理)和 Cglib 代理 (可以在内存动态的创建对象，而不需要实现接口， 他是属于动态代理的范畴) 。下面先通过几个例子理解一下代理模式
静态代理
实例具体要求
- 定义一个接口：
ITeacherDAO - 目标对象
TeacherDAO实现接口ITeacherDAO - 使用静态代理方式,就需要在代理对象
TeacherDAOProxy中也实现ITeacherDAO - 调用的时候通过调用代理对象的方法来调用目标对象.
- 特别提醒：静态代理类与被代理类要实现相同的接口,然后通过调用相同的方法来调用目标对象的方法
public interface ITeacherDao {
void teach(); // 授课的方法
}public class TeacherDao implements ITeacherDao {
@Override
public void teach() {
System.out.println("老师授课中。。。。。");
}
}// 代理对象，静态代理
public class TeacherDaoProxy implements ITeacherDao{
private ITeacherDao target; // 目标对象，通过接口来聚合
// 构造器
public TeacherDaoProxy(ITeacherDao target) {
this.target = target;
}
@Override
public void teach() {
System.out.println("开始代理 完成某些操作。。。。。 "); // 方法
target.teach();
System.out.println("提交。。。。。"); // 方法
}
}public class Client {
public static void main(String[] args) {
// 创建目标对象(被代理对象)
TeacherDao teacherDao = new TeacherDao();
// 创建代理对象, 同时将被代理对象传递给代理对象
TeacherDaoProxy teacherDaoProxy = new TeacherDaoProxy(teacherDao);
// 通过代理对象，调用到被代理对象的方法
// 即：执行的是代理对象的方法，代理对象再去调用目标对象的方法
teacherDaoProxy.teach();
}
}动态代理
代理对象不需要实现接口，但是目标对象要实现接口，否则不能用动态代理
代理对象的生成是利用
JDK的API，动态的在内存中构建代理对象动态代理也叫做：
JDK 代理、接口代理代理类所在包：
java.lang.reflect.ProxyJDK实现代理只需要使用newProxyInstance方法，但是该方法需要接收三个参数，完整的写法是:static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h)
public interface ITeacherDao {
void teach(); // 授课方法
void sayHello(String name);
}public class TeacherDao implements ITeacherDao {
@Override
public void teach() {
System.out.println(" 老师授课中.... ");
}
@Override
public void sayHello(String name) {
System.out.println("hello " + name);
}
}import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
public class ProxyFactory {
// 维护一个目标对象, Object
private Object target;
//构造器，对target进行初始化
public ProxyFactory(Object target) {
this.target = target;
}
// 给目标对象生成一个代理对象
public Object getProxyInstance() {
/* 说明
public static Object newProxyInstance(ClassLoader loader,
Class<?>[] interfaces,
InvocationHandler h)
1. ClassLoader loader：指定当前目标对象使用的类加载器, 获取加载器的方法固定
2. Class<?>[] interfaces: 目标对象实现的接口类型，使用泛型方法确认类型
3. InvocationHandler h: 事情处理，执行目标对象的方法时，会触发事情处理器方法,
会把当前执行的目标对象方法作为参数传入
*/
return Proxy.newProxyInstance(target.getClass().getClassLoader(), target.getClass().getInterfaces(), new InvocationHandler() {
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
System.out.println("JDK代理开始~~");
// 反射机制调用目标对象的方法
Object returnVal = method.invoke(target, args);
System.out.println("JDK代理提交");
return returnVal;
}
});
}
}public class Client {
public static void main(String[] args) {
// 创建目标对象
ITeacherDao target = new TeacherDao();
// 给目标对象创建代理对象, 可以转成 ITeacherDao
ITeacherDao proxyInstance = (ITeacherDao)new ProxyFactory(target).getProxyInstance();
// proxyInstance = class com.sun.proxy.$Proxy0 内存中动态生成了代理对象
System.out.println("proxyInstance = " + proxyInstance.getClass());
// 通过代理对象，调用目标对象的方法
// proxyInstance.teach();
proxyInstance.sayHello(" tom ");
}
}Cglib代理
静态代理和 JDK 代理模式都要求目标对象是实现一个接口，但是有时候目标对象只是一个单独的对象，并没有实现任何的接口，这个时候可使用目标对象子类来实现代理：这就是Cglib代理
Cglib代理也叫作子类代理，它是在内存中构建一个子类对象从而实现对目标对象功能扩展， 有些书也将Cglib代理归属到动态代理。
Cglib 是一个强大的高性能的代码生成包，它可以在运行期扩展 java 类与实现 java 接口。它广泛的被许多 AOP的框架使用，例如 Spring AOP，实现方法拦截
在 AOP 编程中如何选择代理模式：
- 目标对象需要实现接口，用 JDK 代理
- 目标对象不需要实现接口，用 Cglib 代理
Cglib 包的底层是通过使用字节码处理框架 ASM 来转换字节码并生成新的类
需要引入 Cglib 的 jar 文件，在内存中动态构建子类，注意代理的类不能为 final，否则报错
java.lang.IllegalArgumentException，目标对象的方法如果为 final/static，就不会被拦截,即不会执行目标对象额外的业务方法.
public class TeacherDao {
public String teach() {
System.out.println("老师授课中，我是cglib代理，不需要实现接口");
return "hello";
}
}import java.lang.reflect.Method;
import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;
public class ProxyFactory implements MethodInterceptor {
// 维护一个目标对象
private Object target;
// 构造器，传入一个被代理的对象
public ProxyFactory(Object target) {
this.target = target;
}
// 返回一个代理对象: 是 target 对象的代理对象
public Object getProxyInstance() {
// 1.创建一个工具类
Enhancer enhancer = new Enhancer();
// 2.设置父类
enhancer.setSuperclass(target.getClass());
// 3.设置回调函数
enhancer.setCallback(this);
// 4.创建子类对象，即代理对象
return enhancer.create();
}
// 重写intercept 方法，会调用目标对象的方法
@Override
public Object intercept(Object arg0, Method method, Object[] args, MethodProxy arg3) throws Throwable {
System.out.println("Cglib代理模式 ~~ 开始");
Object returnVal = method.invoke(target, args);
System.out.println("Cglib代理模式 ~~ 提交");
return returnVal;
}
}public class Client {
public static void main(String[] args) {
// 创建目标对象
TeacherDao target = new TeacherDao();
// 获取到代理对象，并且将目标对象传递给代理对象
TeacherDao proxyInstance = (TeacherDao)new ProxyFactory(target).getProxyInstance();
// 执行代理对象的方法，触发intecept 方法，从而实现 对目标对象的调用
String res = proxyInstance.teach();
System.out.println("res=" + res);
}
}代理模式的原理解析
代理模式（Proxy Design Pattern）的原理和代码实现都不难掌握。它在不改变原始类（或叫被代理类）代码的情况下，通过引入代理类来给原始类附加功能【装饰器是增强功能，代理是附加新的功能】。
我们开发了一个
MetricsCollector类，用来收集接口请求的原始数据，比如访问时间、处理时长等。在业务系统中，可以采用如下方式来使用这个MetricsCollector类：public class UserController { // ...省略其他属性和方法... private MetricsCollector metricsCollector; // 依赖注入 public UserVo login(String telephone, String password) { long startTimestamp = System.currentTimeMillis(); // ... 省略login逻辑... long endTimeStamp = System.currentTimeMillis(); long responseTime = endTimeStamp - startTimestamp; RequestInfo requestInfo = new RequestInfo("login", responseTime, startTimestamp); metricsCollector.recordRequest(requestInfo); // ...返回UserVo数据... } public UserVo register(String telephone, String password) { long startTimestamp = System.currentTimeMillis(); // ... 省略register逻辑... long endTimeStamp = System.currentTimeMillis(); long responseTime = endTimeStamp - startTimestamp; RequestInfo requestInfo = new RequestInfo("register", responseTime, startTimestamp); metricsCollector.recordRequest(requestInfo); // ...返回UserVo数据... } }很明显，上面的写法有两个问题。第一，性能计数器框架代码侵入到业务代码中，跟业务代码高度耦合。如果未来需要替换这个框架，那替换的成本会比较大。第二，收集接口请求的代码跟业务代码无关，本就不应该放到一个类中。业务类最好职责更加单一，只聚焦业务处理。
为了将框架代码和业务代码解耦，代理模式就派上用场了。代理类
UserControllerProxy和原始类UserController实现相同的接口IUserController。UserController类只负责业务功能。代理类UserControllerProxy负责在业务代码执行前后附加其他逻辑代码，并通过委托的方式调用原始类来执行业务代码。具体的代码实现如下所示：public interface IUserController { UserVo login(String telephone, String password); UserVo register(String telephone, String password); } public class UserController implements IUserController { // ...省略其他属性和方法... @Override public UserVo login(String telephone, String password) { // ...省略login逻辑... // ...返回UserVo数据... } @Override public UserVo register(String telephone, String password) { // ...省略register逻辑... // ...返回UserVo数据... } } public class UserControllerProxy implements IUserController { private MetricsCollector metricsCollector; private UserController userController; public UserControllerProxy(UserController userController) { this.userController = userController; this.metricsCollector = new MetricsCollector(); } @Override public UserVo login(String telephone, String password) { long startTimestamp = System.currentTimeMillis(); // 委托 UserVo userVo = userController.login(telephone, password); long endTimeStamp = System.currentTimeMillis(); long responseTime = endTimeStamp - startTimestamp; RequestInfo requestInfo = new RequestInfo("login", responseTime, startTimestamp); metricsCollector.recordRequest(requestInfo); return userVo; } @Override public UserVo register(String telephone, String password) { long startTimestamp = System.currentTimeMillis(); UserVo userVo = userController.register(telephone, password); long endTimeStamp = System.currentTimeMillis(); long responseTime = endTimeStamp - startTimestamp; RequestInfo requestInfo = new RequestInfo("register", responseTime, startTimestamp); metricsCollector.recordRequest(requestInfo); return userVo; } } // UserControllerProxy使用举例 // 因为原始类和代理类实现相同的接口，是基于接口而非实现编程 // 将UserController类对象替换为UserControllerProxy类对象，不需要改动太多代码 IUserController userController = new UserControllerProxy(new UserController());参照基于接口而非实现编程的设计思想，将原始类对象替换为代理类对象的时候，为了让代码改动尽量少，在刚刚的代理模式的代码实现中，代理类和原始类需要实现相同的接口。但是，如果原始类并没有定义接口，并且原始类代码并不是我们开发维护的（比如它来自一个第三方的类库），我们也没办法直接修改原始类，给它重新定义一个接口。这种情况下该如何实现代理模式呢？
对于这种外部类的扩展，一般都是采用继承的方式。这里也不例外。让代理类继承原始类，然后扩展附加功能。原理很简单，不需要过多解释。具体代码如下所示：
public class UserControllerProxy extends UserController { private MetricsCollector metricsCollector; public UserControllerProxy() { this.metricsCollector = new MetricsCollector(); } public UserVo login(String telephone, String password) { long startTimestamp = System.currentTimeMillis(); UserVo userVo = super.login(telephone, password); long endTimeStamp = System.currentTimeMillis(); long responseTime = endTimeStamp - startTimestamp; RequestInfo requestInfo = new RequestInfo("login", responseTime, startTimestamp); metricsCollector.recordRequest(requestInfo); return userVo; } public UserVo register(String telephone, String password) { long startTimestamp = System.currentTimeMillis(); UserVo userVo = super.register(telephone, password); long endTimeStamp = System.currentTimeMillis(); long responseTime = endTimeStamp - startTimestamp; RequestInfo requestInfo = new RequestInfo("register", responseTime, startTimestamp); metricsCollector.recordRequest(requestInfo); return userVo; } } // UserControllerProxy使用举例 UserController userController = new UserControllerProxy();
动态代理的原理解析
不过，刚刚的代码实现还是有点问题。一方面，需要在代理类中将原始类中的所有的方法，都重新实现一遍，并且为每个方法都附加相似的代码逻辑。另一方面，如果要添加的附加功能的类有不止一个，需要针对每个类都创建一个代理类。
如果有 50 个要添加附加功能的原始类，那我们就要创建 50 个对应的代理类。这会导致项目中类的个数成倍增加，增加了代码维护成本。并且，每个代理类中的代码都有点像模板式的“重复”代码，也增加了不必要的开发成本。那这个问题怎么解决呢？
可以使用动态代理来解决这个问题。所谓动态代理（Dynamic Proxy），就是不事先为每个原始类编写代理类，而是在运行的时候，动态地创建原始类对应的代理类，然后在系统中用代理类替换掉原始类。那如何实现动态代理呢？
Java 语言本身就已经提供了动态代理的语法（实际上，动态代理底层依赖的就是 Java 的反射语法）。来看如何用 Java 的动态代理来实现刚刚的功能。具体的代码如下所示。其中，
MetricsCollectorProxy作为一个动态代理类，动态地给每个需要收集接口请求信息的类创建代理类。public class MetricsCollectorProxy { private MetricsCollector metricsCollector; public MetricsCollectorProxy() { this.metricsCollector = new MetricsCollector(); } public Object createProxy(Object proxiedObject) { Class<?>[] interfaces = proxiedObject.getClass().getInterfaces(); DynamicProxyHandler handler = new DynamicProxyHandler(proxiedObject); return Proxy.newProxyInstance(proxiedObject.getClass().getClassLoader(), interfaces, handler); } private class DynamicProxyHandler implements InvocationHandler { private Object proxiedObject; public DynamicProxyHandler(Object proxiedObject) { this.proxiedObject = proxiedObject; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { long startTimestamp = System.currentTimeMillis(); Object result = method.invoke(proxiedObject, args); long endTimeStamp = System.currentTimeMillis(); long responseTime = endTimeStamp - startTimestamp; String apiName = proxiedObject.getClass().getName() + ":" + method.getName(); RequestInfo requestInfo = new RequestInfo(apiName, responseTime, startTimestamp); metricsCollector.recordRequest(requestInfo); return result; } } } // MetricsCollectorProxy使用举例 MetricsCollectorProxy proxy = new MetricsCollectorProxy(); IUserController userController = (IUserController) proxy.createProxy(new UserController());实际上，Spring AOP 底层的实现原理就是基于动态代理。用户配置好需要给哪些类创建代理，并定义好在执行原始类的业务代码前后执行哪些附加功能。Spring 为这些类创建动态代理对象，并在 JVM 中替代原始类对象。原本在代码中执行的原始类的方法，被换作执行代理类的方法，也就实现了给原始类添加附加功能的目的。
代理模式的应用场景
业务系统的非功能性需求开发
代理模式最常用的一个应用场景就是，在业务系统中开发一些非功能性需求，比如：监控、统计、鉴权、限流、事务、幂等、日志。将这些附加功能与业务功能解耦，放到代理类中统一处理，让程序员只需要关注业务方面的开发。实际上，前面举的搜集接口请求信息的例子，就是这个应用场景的一个典型例子。
如果你熟悉 Java 语言和 Spring 开发框架，这部分工作都是可以在 Spring AOP 切面中完成的。前面也提到，Spring AOP 底层的实现原理就是基于动态代理。
代理模式在 RPC、缓存中的应用
实际上，RPC 框架也可以看作一种代理模式，GoF 的《设计模式》一书中把它称作远程代理。通过远程代理，将网络通信、数据编解码等细节隐藏起来。客户端在使用 RPC 服务的时候，就像使用本地函数一样，无需了解跟服务器交互的细节。除此之外，RPC 服务的开发者也只需要开发业务逻辑，就像开发本地使用的函数一样，不需要关注跟客户端的交互细节。
代理模式在缓存中的应用
- 假设要开发一个接口请求的缓存功能，对于某些接口请求，如果入参相同，在设定的过期时间内，直接返回缓存结果，而不用重新进行逻辑处理。比如，针对获取用户个人信息的需求，可以开发两个接口，一个支持缓存，一个支持实时查询。对于需要实时数据的需求，我们让其调用实时查询接口，对于不需要实时数据的需求，我们让其调用支持缓存的接口。那如何来实现接口请求的缓存功能呢？
- 最简单的实现方法就是刚刚我们讲到的，给每个需要支持缓存的查询需求都开发两个不同的接口，一个支持缓存，一个支持实时查询。但是，这样做显然增加了开发成本，而且会让代码看起来非常臃肿（接口个数成倍增加），也不方便缓存接口的集中管理（增加、删除缓存接口）、集中配置（比如配置每个接口缓存过期时间）。
- 针对这些问题，代理模式就能派上用场了，确切地说，应该是动态代理。如果是基于 Spring 框架来开发的话，那就可以在 AOP 切面中完成接口缓存的功能。在应用启动的时候，我们从配置文件中加载需要支持缓存的接口，以及相应的缓存策略（比如过期时间）等。当请求到来的时候，我们在 AOP 切面中拦截请求，如果请求中带有支持缓存的字段（比如 http://…?..&cached=true），我们便从缓存（内存缓存或者 Redis 缓存等）中获取数据直接返回。
桥接模式【常用】
- 上一节学习了第一种结构型模式：代理模式。它在不改变原始类（或者叫被代理类）代码的情况下，通过引入代理类来给原始类附加功能。代理模式在平时的开发经常被用到，常用在业务系统中开发一些非功能性需求，比如：监控、统计、鉴权、限流、事务、幂等、日志。
- 接下来再学习另外一种结构型模式：桥接模式。桥接模式的代码实现非常简单，但是理解起来稍微有点难度，并且应用场景也比较局限，所以，相当于代理模式来说，桥接模式在实际的项目中并没有那么常用，只需要简单了解，见到能认识就可以，并不是我们学习的重点。
- 我们依旧是先看比较简单的例子
Demo案例 - 手机操作问题
需求
现在对不同手机类型的不同品牌实现操作编程(比如：开机、关机、上网，打电话等)，如图:
传统方案解决手机操作问题分析
- 扩展性问题(类爆炸)，如果再增加手机的样式(旋转式)，就需要增加各个品牌手机的类，同样如果增加一个手机品牌，也要在各个手机样式类下增加。
- 违反了单一职责原则，当增加手机样式时，要同时增加所有品牌的手机，这样增加了代码维护成本.
- 解决方案-使用桥接模式
Bridge模式基于类的最小设计原则，通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来，从而可以保持各部分的独立性以及应对他们的功能扩展。
使用桥接模式的代码
// Brand接口
public interface Brand {
void open();
void close();
void call();
}// Phone抽象类
public abstract class Phone {
// 组合品牌
private Brand brand;
// 构造器
public Phone(Brand brand) {
super();
this.brand = brand;
}
protected void open() {
this.brand.open();
}
protected void close() {
brand.close();
}
protected void call() {
brand.call();
}
}// Vivo手机
public class Vivo implements Brand {
@Override
public void open() {
System.out.println(" Vivo手机开机 ");
}
@Override
public void close() {
System.out.println(" Vivo手机关机 ");
}
@Override
public void call() {
System.out.println(" Vivo手机打电话 ");
}
}// 小米手机
public class XiaoMi implements Brand {
@Override
public void open() {
System.out.println(" 小米手机开机 ");
}
@Override
public void close() {
System.out.println(" 小米手机关机 ");
}
@Override
public void call() {
System.out.println(" 小米手机打电话 ");
}
}// 折叠式手机类，继承抽象类Phone
public class FoldedPhone extends Phone {
// 构造器
public FoldedPhone(Brand brand) {
super(brand);
}
public void open() {
super.open();
System.out.println(" 折叠样式手机 ");
}
public void close() {
super.close();
System.out.println(" 折叠样式手机 ");
}
public void call() {
super.call();
System.out.println(" 折叠样式手机 ");
}
}// 直立样式手机
public class UpRightPhone extends Phone {
// 构造器
public UpRightPhone(Brand brand) {
super(brand);
}
public void open() {
super.open();
System.out.println(" 直立样式手机 ");
}
public void close() {
super.close();
System.out.println(" 直立样式手机 ");
}
public void call() {
super.call();
System.out.println(" 直立样式手机 ");
}
}public class Client {
public static void main(String[] args) {
// 获取折叠式手机 (样式 + 品牌 )
Phone phone1 = new FoldedPhone(new XiaoMi());
phone1.open();
phone1.call();
phone1.close();
Phone phone2 = new FoldedPhone(new Vivo());
phone2.open();
phone2.call();
phone2.close();
UpRightPhone phone3 = new UpRightPhone(new XiaoMi());
phone3.open();
phone3.call();
phone3.close();
UpRightPhone phone4 = new UpRightPhone(new Vivo());
phone4.open();
phone4.call();
phone4.close();
}
}桥接模式，也叫作桥梁模式，英文是Bridge Design Pattern。这个模式可以说是 23 种设计模式中最难理解的模式之一了。对于这个模式主要有两种不同的理解方式。
当然，这其中“最纯正”的理解方式，当属 GoF 的《设计模式》一书中对桥接模式的定义。毕竟，这 23 种经典的设计模式，最初就是由这本书总结出来的。在 GoF 的《设计模式》一书中，桥接模式是这么定义的：“Decouple an abstraction from its implementation so that the two can vary independently。”翻译成中文就是：“将抽象和实现解耦，让它们可以独立变化。”
关于桥接模式，很多书籍、资料中还有另外一种理解方式：“一个类存在两个（或多个）独立变化的维度，通过组合的方式让这两个（或多个）维度可以独立进行扩展。通过组合关系来替代继承关系，避免继承层次的指数级爆炸。“这种理解方式非常类似于“组合优于继承”设计原则。重点看下 GoF 的理解方式。
GoF 给出的定义非常的简短，单凭这一句话，估计没几个人能看懂是什么意思。所以，通过
JDBC驱动的例子来解释一下。JDBC驱动是桥接模式的经典应用。先来看一下如何利用JDBC驱动来查询数据库。具体的代码如下所示：Class.forName("com.mysql.jdbc.Driver"); // 加载及注册JDBC驱动程序 String url = "jdbc:mysql://localhost:3306/sample_db?user=root&password=your_password"; Connection con = DriverManager.getConnection(url); Statement stmt = con.createStatement(); String query = "select * from test"; ResultSet rs = stmt.executeQuery(query); while (rs.next()) { rs.getString(1); rs.getInt(2); }如果想要把 MySQL 数据库换成 Oracle 数据库，只需要把第一行代码中的 com.mysql.jdbc.Driver 换成 oracle.jdbc.driver.OracleDriver 就可以了。当然，也有更灵活的实现方式，可以把需要加载的 Driver 类写到配置文件中，当程序启动的时候，自动从配置文件中加载，这样在切换数据库的时候，我们都不需要修改代码，只需要修改配置文件就可以了。
不管是改代码还是改配置，在项目中，从一个数据库切换到另一种数据库，都只需要改动很少的代码，或者完全不需要改动代码，那如此优雅的数据库切换是如何实现的呢？
源码之下无秘密。要弄清楚这个问题，先从 com.mysql.jdbc.Driver 这个类的代码看起。
package com.mysql.jdbc; import java.sql.SQLException; public class Driver extends NonRegisteringDriver implements java.sql.Driver { static { try { java.sql.DriverManager.registerDriver(new Driver()); } catch (SQLException E) { throw new RuntimeException("Can't register driver!"); } } /** * Construct a new driver and register it with DriverManager * @throws SQLException if a database error occurs. */ public Driver() throws SQLException { // Required for Class.forName().newInstance() } }
结合 com.mysql.jdbc.Driver 的代码实现，可以发现，当执行Class.forName("com.mysql.jdbc.Driver")这条语句的时候，实际上是做了两件事情。第一件事情是要求 JVM 查找并加载指定的 Driver 类，第二件事情是执行该类的静态代码块，也就是将 MySQL Driver 注册到DriverManager类中。
现在再来看DriverManager类是干什么用的。具体的代码如下所示。当我们把具体的 Driver 实现类（比如，com.mysql.jdbc.Driver）注册到DriverManager之后，后续所有对 JDBC 接口的调用，都会委派到对具体的 Driver 实现类来执行。而 Driver 实现类都实现了相同的接口（java.sql.Driver），这也是可以灵活切换 Driver 的原因。
public class DriverManager {
private static final CopyOnWriteArrayList<DriverInfo> registeredDrivers = = new CopyOnWriteArrayList();
// ...
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}
// ...
public static synchronized void registerDriver(java.sql.Driver driver) throws SQLException {
if (driver != null) {
registeredDrivers.addIfAbsent(new DriverInfo(driver));
} else {
throw new NullPointerException();
}
}
public static Connection getConnection(String url, String user, String password) throws SQLException {
java.util.Properties info = new java.util.Properties();
if (user != null) {
info.put("user", user);
}
if (password != null) {
info.put("password", password);
}
return (getConnection(url, info, Reflection.getCallerClass()));
}
// ...
}桥接模式的定义是“将抽象和实现解耦，让它们可以独立变化”。那弄懂定义中“抽象”和“实现”两个概念，就是理解桥接模式的关键。那在 JDBC 这个例子中，什么是“抽象”？什么是“实现”呢？
实际上，JDBC 本身就相当于“抽象”。注意，这里所说的“抽象”，指的并非“抽象类”或“接口”，而是跟具体的数据库无关的、被抽象出来的一套“类库”。具体的 Driver（比如，com.mysql.jdbc.Driver）就相当于“实现”。注意，这里所说的“实现”，也并非指“接口的实现类”，而是跟具体数据库相关的一套“类库”。JDBC 和 Driver 独立开发，通过对象之间的组合关系，组装在一起。JDBC 的所有逻辑操作，最终都委托给 Driver 来执行。
桥接模式的应用举例
前面讲过一个 API 接口监控告警的例子：根据不同的告警规则，触发不同类型的告警。告警支持多种通知渠道，包括：邮件、短信、微信、自动语音电话。通知的紧急程度有多种类型，包括：SEVERE（严重）、URGENCY（紧急）、NORMAL（普通）、TRIVIAL（无关紧要）。不同的紧急程度对应不同的通知渠道。比如，SEVERE（严重）级别的消息会通过“自动语音电话”告知相关人员。
在当时的代码实现中，关于发送告警信息那部分代码，只给出了粗略的设计，现在来一块实现一下。我们先来看最简单、最直接的一种实现方式。代码如下所示：
public enum NotificationEmergencyLevel {
SEVERE,
URGENCY,
NORMAL,
TRIVIAL
}
public class Notification {
private List<String> emailAddresses;
private List<String> telephones;
private List<String> wechatIds;
public Notification() {}
public void setEmailAddress(List<String> emailAddress) {
this.emailAddresses = emailAddress;
}
public void setTelephones(List<String> telephones) {
this.telephones = telephones;
}
public void setWechatIds(List<String> wechatIds) {
this.wechatIds = wechatIds;
}
public void notify(NotificationEmergencyLevel level, String message) {
if (level.equals(NotificationEmergencyLevel.SEVERE)) {
// ...自动语音电话
} else if (level.equals(NotificationEmergencyLevel.URGENCY)) {
// ...发微信
} else if (level.equals(NotificationEmergencyLevel.NORMAL)) {
// ...发邮件
} else if (level.equals(NotificationEmergencyLevel.TRIVIAL)) {
// ...发邮件
}
}
}
// 在API监控告警的例子中，如下方式来使用Notification类：
public class ErrorAlertHandler extends AlertHandler {
public ErrorAlertHandler(AlertRule rule, Notification notification) {
super(rule, notification);
}
@Override
public void check(ApiStatInfo apiStatInfo) {
if (apiStatInfo.getErrorCount() > rule.getMatchedRule(apiStatInfo.getApi()).getMaxErrorCount()) {
notification.notify(NotificationEmergencyLevel.SEVERE, "...");
}
}
}Notification类的代码实现有一个最明显的问题，那就是有很多if-else分支逻辑。实际上，如果每个分支中的代码都不复杂，后期也没有无限膨胀的可能（增加更多if-else分支判断），那这样的设计问题并不大，没必要非得一定要摒弃if-else分支逻辑。- 不过，
Notification的代码显然不符合这个条件。因为每个if-else分支中的代码逻辑都比较复杂，发送通知的所有逻辑都扎堆在Notification类中。类的代码越多，就越难读懂，越难修改，维护的成本也就越高。很多设计模式都是试图将庞大的类拆分成更细小的类，然后再通过某种更合理的结构组装在一起。 - 针对
Notification的代码，将不同渠道的发送逻辑剥离出来，形成独立的消息发送类（MsgSender 相关类）。其中，Notification类相当于抽象，MsgSender类相当于实现，两者可以独立开发，通过组合关系（也就是桥梁）任意组合在一起。所谓任意组合的意思就是，不同紧急程度的消息和发送渠道之间的对应关系，不是在代码中固定写死的，可以动态地去指定（比如，通过读取配置来获取对应关系）。
按照这个设计思路对代码进行重构。重构之后的代码如下所示：
public interface MsgSender {
void send(String message);
}
public class TelephoneMsgSender implements MsgSender {
private List<String> telephones;
public TelephoneMsgSender(List<String> telephones) {
this.telephones = telephones;
}
@Override
public void send(String message) {
// ...
}
}
public class EmailMsgSender implements MsgSender {
// 与TelephoneMsgSender代码结构类似，所以省略...
}
public class WechatMsgSender implements MsgSender {
// 与TelephoneMsgSender代码结构类似，所以省略...
}
public abstract class Notification {
protected MsgSender msgSender;
public Notification(MsgSender msgSender) {
this.msgSender = msgSender;
}
public abstract void notify(String message);
}
public class SevereNotification extends Notification {
public SevereNotification(MsgSender msgSender) {
super(msgSender);
}
@Override
public void notify(String message) {
msgSender.send(message);
}
}
public class UrgencyNotification extends Notification {
// 与SevereNotification代码结构类似，所以省略...
}
public class NormalNotification extends Notification {
// 与SevereNotification代码结构类似，所以省略...
}
public class TrivialNotification extends Notification {
// 与SevereNotification代码结构类似，所以省略...
}
桥接模式的注意事项和细节
- 实现了抽象和实现部分的分离，从而极大的提供了系统的灵活性，让抽象部分和实现部分独立开来，这有助于系统进行分层设计，从而产生更好的结构化系统。
- 对于系统的高层部分，只需要知道抽象部分和实现部分的接口就可以了，其它的部分由具体业务来完成。
- 桥接模式替代多层继承方案，可以减少子类的个数，降低系统的管理和维护成本
- 桥接模式的引入增加了系统的理解和设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计和编程
- 桥接模式要求**正确识别出系统中两个独立变化的维度(抽象、和实现)**，因此其使用范围有一定的局限性，即需要有这样的应用场景。
- 桥接模式有两种理解方式。第一种理解方式是“将抽象和实现解耦，让它们能独立开发”。这种理解方式比较特别，应用场景也不多。另一种理解方式更加简单，类似“组合优于继承”设计原则，这种理解方式更加通用，应用场景比较多。不管是哪种理解方式，它们的代码结构都是相同的，都是一种类之间的组合关系。
装饰器模式【常用】
下面通过剖析 Java IO 类的设计思想，再学习一种新的结构型模式，装饰器模式。它的代码结构跟桥接模式非常相似，不过，要解决的问题却大不相同。
### **Demo案例 - 咖啡订单项目**星巴克咖啡订单项目
- 咖啡种类 / 单品咖啡：Espresso(意大利浓咖啡)、ShortBlack、LongBlack(美式咖啡)、Decaf(无因咖啡)
- 调料：Milk、Soy(豆浆)、Chocolate
- 要求在扩展新的咖啡种类时，具有良好的扩展性、改动方便、维护方便
- 客户可以点单品咖啡，也可以单品咖啡+调料组合。
方案一
- Drink 是一个抽象类，表示饮料
- des 就是对咖啡的描述, 比如咖啡的名字
- cost() 方法就是计算费用，Drink 类中做成一个抽象方法.
- Decaf 就是单品咖啡， 继承 Drink, 并实现 cost
- Espress && Milk 就是单品咖啡+调料， 这个组合很多
- 问题：这样设计，会有很多类，当我们增加一个单品咖啡，或者一个新的调料，类的数量就会倍增，就会出现类爆炸
方案二
前面分析到方案 1 因为咖啡单品+调料组合会造成类的倍增，因此可以做改进，将调料内置到 Drink 类，这样就不会造成类数量过多。从而提高项目的维护性(如图)
- 方案 2 可以控制类的数量，不至于造成很多的类
- 在增加或者删除调料种类时，代码的维护量很大
- 考虑到用户可以添加多份 调料时，可以将 hasMilk 返回一个对应 int
- 考虑使用 装饰器 模式
// Drink(抽象类)
public abstract class Drink {
public String des; // 描述
private float price = 0.0f;
public String getDes() {
return des;
}
public void setDes(String des) {
this.des = des;
}
public float getPrice() {
return price;
}
public void setPrice(float price) {
this.price = price;
}
// 计算费用的抽象方法
// 子类来实现
public abstract float cost();
}// Decorator
public class Decorator extends Drink {
private Drink obj;
public Decorator(Drink obj) { // 组合
this.obj = obj;
}
@Override
public float cost() {
// 费用的叠加计算
return super.getPrice() + obj.cost();
}
@Override
public String getDes() {
// obj.getDes() 输出被装饰者的信息
return des + " " + getPrice() + " && " + obj.getDes();
}
}// Coffee
public class Coffee extends Drink {
@Override
public float cost() {
return super.getPrice();
}
}// ShortBlack
public class ShortBlack extends Coffee{
public ShortBlack() {
setDes("shortblack");
setPrice(4.0f);
}
}// LongBlack
public class LongBlack extends Coffee {
public LongBlack() {
setDes(" longblack ");
setPrice(5.0f);
}
}// DeCaf
public class DeCaf extends Coffee {
public DeCaf() {
setDes(" 无因咖啡 ");
setPrice(1.0f);
}
}// Espresso
public class Espresso extends Coffee {
public Espresso() {
setDes(" 意大利咖啡 ");
setPrice(6.0f);
}
}// 具体的Decorator，这里就是调味品
public class Chocolate extends Decorator {
public Chocolate(Drink obj) {
super(obj);
setDes(" 巧克力 ");
setPrice(3.0f); // 调味品的价格
}
}// Milk
public class Milk extends Decorator {
public Milk(Drink obj) {
super(obj);
setDes(" 牛奶 ");
setPrice(2.0f);
}
}// Soy
public class Soy extends Decorator{
public Soy(Drink obj) {
super(obj);
setDes(" 豆浆 ");
setPrice(1.5f);
}
}// CoffeeBar
public class CoffeeBar {
public static void main(String[] args) {
// 装饰器模式下的订单：2份巧克力 + 一份牛奶的LongBlack
// 1. 点一份 LongBlack
Drink order = new LongBlack(); // 向下转型
System.out.println("费用1 = " + order.cost());
System.out.println("描述 = " + order.getDes());
// 2. order 加入一份牛奶
order = new Milk(order);
System.out.println("order 加入一份牛奶 费用 = " + order.cost());
System.out.println("order 加入一份牛奶 描述 = " + order.getDes());
// 3. order 加入一份巧克力
order = new Chocolate(order);
System.out.println("order 加入一份牛奶 加入一份巧克力 费用 =" + order.cost());
System.out.println("order 加入一份牛奶 加入一份巧克力 描述 = " + order.getDes());
// 3. order 加入一份巧克力
order = new Chocolate(order);
System.out.println("order 加入一份牛奶 加入2份巧克力 费用 =" + order.cost());
System.out.println("order 加入一份牛奶 加入2份巧克力 描述 = " + order.getDes());
System.out.println("===========================");
Drink order2 = new DeCaf();
System.out.println("order2 无因咖啡 费用 = " + order2.cost());
System.out.println("order2 无因咖啡 描述 = " + order2.getDes());
order2 = new Milk(order2);
System.out.println("order2 无因咖啡 加入一份牛奶 费用 = " + order2.cost());
System.out.println("order2 无因咖啡 加入一份牛奶 描述 = " + order2.getDes());
}
}装饰器模式原理
装饰器模式就像打包一个快递
- 主体：比如：陶瓷、衣服 (Component)，被装饰者，类似前面的 Drink
- ConcreteComponent：具体的主体， 比如前面的各个单品咖啡
- 包装：比如：报纸填充、塑料泡沫、纸板、木板(Decorator)
在Component 与 ConcreteComponent 之间，如果 ConcreteComponent 类很多，还可以设计一个缓冲层，将共有的部分提取出来，抽象成一个类
Java IO 类的“奇怪”用法
Java IO 类库非常庞杂，有几十个类，负责 IO 数据的读取和写入。如果对 Java IO 类做一下分类，可以从下面两个维度将它划分为四类。具体见下面的表格：
| 字节流 | 字符流 | |
|---|---|---|
| 输入流 | InputStream | Reader |
| 输出流 | OutputStream | Writer |
针对不同的读取和写入场景，Java IO 又在这四个父类基础之上，扩展出了很多子类。具体如下所示：
说明
- InputStream 是抽象类, 类似前面讲的 Drink
- FileInputStream 是 InputStream 子类，类似前面的 DeCaf, LongBlack
- FilterInputStream 是 InputStream 子类：类似前面 的 Decorator 修饰器
- DataInputStream 是 FilterInputStream 子类，具体的修饰者，类似前面的 Milk, Soy 等
- FilterInputStream 类 有 protected volatile InputStream in; 即含被装饰者
- 分析得出在jdk 的io体系中，就是使用的装饰器模式
在我初学 Java 的时候，曾经对 Java IO 的一些用法产生过很大疑惑，比如下面这样一段代码。我们打开文件 test.txt，从中读取数据。其中，InputStream 是一个抽象类，FileInputStream 是专门用来读取文件流的子类。BufferedInputStream 是一个支持带缓存功能的数据读取类，可以提高数据读取的效率。
InputStream in = new FileInputStream("/user/test.txt");
InputStream bin = new BufferedInputStream(in);
byte[] data = new byte[128];
while (bin.read(data) != -1) {
// ...
}初看上面的代码，我们会觉得 Java IO 的用法比较麻烦，需要先创建一个FileInputStream对象，然后再传递给 BufferedInputStream对象来使用。我在想，Java IO 为什么不设计一个继承FileInputStream并且支持缓存的 BufferedFileInputStream类呢？这样我们就可以像下面的代码中这样，直接创建一个BufferedFileInputStream类对象，打开文件读取数据，用起来岂不是更加简单？
InputStream bin = new BufferedFileInputStream("/user/test.txt");
byte[] data = new byte[128];
while (bin.read(data) != -1) {
// ...
}基于继承的设计方案
如果InputStream只有一个子类 FileInputStream 的话，那我们在FileInputStream基础之上，再设计一个孙子类 BufferedFileInputStream，也算是可以接受的，毕竟继承结构还算简单。但实际上，继承于InputStream的子类有很多。我们需要给每一个InputStream的子类再继续派生支持缓存读取的子类。
除了支持缓存读取之外，如果还需要对功能进行其他方面的增强，比如下面的DataInputStream类，支持按照基本数据类型（int、boolean、long 等）来读取数据。
FileInputStream in = new FileInputStream("/user/test.txt");
DataInputStream din = new DataInputStream(in);
int data = din.readInt();在这种情况下，如果继续按照继承的方式来实现的话，就需要再继续派生出DataFileInputStream、DataPipedInputStream等类。如果还需要既支持缓存、又支持按照基本类型读取数据的类，那就要再继续派生出 BufferedDataFileInputStream、BufferedDataPipedInputStream等 n 多类。这还只是附加了两个增强功能，如果我们需要附加更多的增强功能，那就会导致组合爆炸，类继承结构变得无比复杂，代码既不好扩展，也不好维护。这也是不推荐使用继承的原因。
基于装饰器模式的设计方案
前面还讲到“组合优于继承”，可以“使用组合来替代继承”。针对刚刚的继承结构过于复杂的问题，可以通过将继承关系改为组合关系来解决。下面的代码展示了 Java IO 的这种设计思路。
import java.io.IOException;
public abstract class InputStream {
// ...
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 {
return 0;
}
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;
}
}
public class BufferedInputStream extends InputStream {
protected volatile InputStream in;
protected BufferedInputStream(InputStream in) {
this.in = in;
}
// ...实现基于缓存的读数据接口...
}
public class DataInputStream extends InputStream {
protected volatile InputStream in;
protected DataInputStream(InputStream in) {
this.in = in;
}
// ...实现读取基本类型数据的接口
}看了上面的代码，你可能会问，那装饰器模式就是简单的“用组合替代继承”吗？当然不是。从 Java IO 的设计来看，装饰器模式相对于简单的组合关系，还有两个比较特殊的地方。
第一个比较特殊的地方是：装饰器类和原始类继承同样的父类，这样我们可以对原始类“嵌套”多个装饰器类。比如，下面的代码对FileInputStream嵌套了两个装饰器类：BufferedInputStream和DataInputStream，让它既支持缓存读取，又支持按照基本数据类型来读取数据。
InputStream in = new FileInputStream("/user/test.txt");
InputStream bin = new BufferedInputStream(in);
DataInputStream din = new DataInputStream(bin);
int data = din.readInt();第二个比较特殊的地方是：装饰器类是对功能的增强，这也是装饰器模式应用场景的一个重要特点。实际上，符合“组合关系”这种代码结构的设计模式有很多，比如之前讲过的代理模式、桥接模式，还有现在的装饰器模式。尽管它们的代码结构很相似，但是每种设计模式的意图是不同的。就拿比较相似的代理模式和装饰器模式来说吧，代理模式中，代理类附加的是跟原始类无关的功能，而在装饰器模式中，装饰器类附加的是跟原始类相关的增强功能。
// 代理模式的代码结构(下面的接口也可以替换成抽象类)
public interface IA {
void f();
}
public class A impelements IA {
public void f() {
// ...
}
}
public class AProxy impements IA {
private IA a;
public AProxy(IA a) {
this.a = a;
}
public void f() {
// 新添加的代理逻辑
a.f();
// 新添加的代理逻辑
}
}
// 装饰器模式的代码结构(下面的接口也可以替换成抽象类)
public interface IA {
void f();
}
public class A impelements IA {
public void f() {
// ...
}
}
public class ADecorator impements IA {
private IA a;
public ADecorator(IA a) {
this.a = a;
}
public void f() {
// 功能增强代码
a.f();
// 功能增强代码
}
}- 实际上，如果去查看 JDK 的源码，你会发现，
BufferedInputStream、DataInputStream并非继承自InputStream，而是另外一个叫 FilterInputStream 的类。那这又是出于什么样的设计意图，才引入这样一个类呢？ - 再重新看一下
BufferedInputStream类的代码。InputStream是一个抽象类而非接口，而且它的大部分函数（比如 read()、available()）都有默认实现，按理来说，我们只需要在BufferedInputStream类中重新实现那些需要增加缓存功能的函数就可以了，其他函数继承InputStream的默认实现。但实际上，这样做是行不通的。 - 对于即便是不需要增加缓存功能的函数来说，
BufferedInputStream还是必须把它重新实现一遍，简单包裹对InputStream对象的函数调用。具体的代码示例如下所示。如果不重新实现，那BufferedInputStream类就无法将最终读取数据的任务，委托给传递进来的InputStream对象来完成。
public class BufferedInputStream extends InputStream {
protected volatile InputStream in;
protected BufferedInputStream(InputStream in) {
this.in = in;
}
// f()函数不需要增强，只是重新调用一下InputStream in对象的f()
public void f() {
in.f();
}
}实际上，DataInputStream也存在跟BufferedInputStream同样的问题。为了避免代码重复，Java IO 抽象出了一个装饰器父类FilterInputStream，代码实现如下所示。InputStream 的所有的装饰器类（BufferedInputStream、DataInputStream）都继承自这个装饰器父类。这样，装饰器类只需要实现它需要增强的方法就可以了，其他方法继承装饰器父类的默认实现。
public class FilterInputStream extends InputStream {
protected volatile InputStream in;
protected FilterInputStream(InputStream in) {
this.in = in;
}
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[], int off, int len) throws IOException {
return in.read(b, off, len);
}
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();
}
}适配器模式【常用】
- 前面学了代理模式、桥接模式、装饰器模式，下面再来学习一个比较常用的结构型模式：适配器模式。这个模式相对来说还是比较简单、好理解的，应用场景也很具体，总体上来讲比较好掌握。
- 关于适配器模式，主要学习它的两种实现方式，类适配器和对象适配器，以及 5 种常见的应用场景。同时，通过剖析
slf4j日志框架，来展示这个模式在真实项目中的应用。除此之外，在文章的最后，还对代理、桥接、装饰器、适配器，这 4 种代码结构非常相似的设计模式做简单的对比，对这几节内容做一个简单的总结。 - 适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表示，主要的目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper) 。适配器模式属于结构型模式。主要分为三类：类适配器模式、对象适配器模式、接口适配器模式
Demo案例 - 充电器
基本介绍：Adapter 类，通过继承 src 类，实现 dst 类接口，完成 src → dst 的适配。
- 以生活中充电器的例子来讲解适配器，充电器本身相当于 Adapter，220V 交流电相当于 src (即被适配者)，我们的目 dst(即目标)是 5V 直流电
类适配器代码实现
// 被适配的类
public class Voltage220V {
// 输出220V的电压
public int output220V() {
int src = 220;
System.out.println("电压 = " + src + "伏");
return src;
}
}// 适配接口
public interface IVoltage5V {
public int output5V();
}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 class VoltageAdapter extends Voltage220V implements IVoltage5V {
@Override
public int output5V() {
// 获取到220V电压
int srcV = output220V();
int dstV = srcV / 44 ; // 转成5v
return dstV;
}
}public class Client {
public static void main(String[] args) {
System.out.println(" ==== 类适配器模式 ====");
Phone phone = new Phone();
phone.charging(new VoltageAdapter());
}
}对象适配器实现
基本思路和类的适配器模式相同，只是将 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;
}
}public class Client {
public static void main(String[] args) {
System.out.println(" ==== 对象适配器模式 ====");
Phone phone = new Phone();
phone.charging(new VoltageAdapter(new Voltage220V()));
}
}适配器模式的原理与实现
顾名思义，这个模式就是用来做适配的，它将不兼容的接口转换为可兼容的接口，让原本由于接口不兼容而不能一起工作的类可以一起工作。对于这个模式，有一个经常被拿来解释它的例子，就是 USB 转接头充当适配器，把两种不兼容的接口，通过转接变得可以一起工作。
原理很简单，再来看下它的代码实现。适配器模式有两种实现方式：类适配器和对象适配器。其中，类适配器使用继承关系来实现，对象适配器使用组合关系来实现。具体的代码实现如下所示。其中，ITarget表示要转化成的接口定义。Adaptee是一组不兼容 ITarget 接口定义的接口，Adaptor将Adaptee转化成一组符合ITarget接口定义的接口。
// 类适配器: 基于继承
public interface ITarget {
void f1();
void f2();
void fc();
}
public class Adaptee {
public void fa() {
// ...
}
public void fb() {
// ...
}
public void fc(){
// ...
}
}
public class Adaptor extends Adaptee implements ITarget {
public void f1() {
super.fa();
}
public void f2() {
// ...重新实现f2()...
}
// 这里fc()不需要实现，直接继承自Adaptee，这是跟对象适配器最大的不同点
}
// 对象适配器：基于组合
public interface ITarget {
void f1();
void f2();
void fc();
}
public class Adaptee {
public void fa() {
// ...
}
public void fb() {
// ...
}
public void fc(){
// ...
}
}
public class Adaptor implements ITarget {
private Adaptee adaptee;
public Adaptor(Adaptee adaptee) {
this.adaptee = adaptee;
}
public void f1() {
adaptee.fa(); // 委托给Adaptee
}
public void f2() {
// ...重新实现f2()...
}
public void fc() {
adaptee.fc();
}
}针对这两种实现方式，在实际的开发中，到底该如何选择使用哪一种呢？判断的标准主要有两个，一个是Adaptee接口的个数，另一个是Adaptee和ITarget的契合程度。
- 如果
Adaptee接口并不多，那两种实现方式都可以。 - 如果
Adaptee接口很多，而且Adaptee和ITarget接口定义大部分都相同，那推荐使用类适配器，因为Adaptor复用父类Adaptee的接口，比起对象适配器的实现方式，Adaptor的代码量要少一些。 - 如果
Adaptee接口很多，而且Adaptee和ITarget接口定义大部分都不相同，那推荐使用对象适配器，因为组合结构相对于继承更加灵活。
适配器模式应用场景总结
- 原理和实现讲完了，都不复杂。再来看到底什么时候会用到适配器模式呢？
- 一般来说，适配器模式可以看作一种“补偿模式”，用来补救设计上的缺陷。应用这种模式算是“无奈之举”。如果在设计初期，就能协调规避接口不兼容的问题，那这种模式就没有应用的机会了。
- 前面反复提到，适配器模式的应用场景是“接口不兼容”。那在实际的开发中，什么情况下才会出现接口不兼容呢？
封装有缺陷的接口设计
假设我们依赖的外部系统在接口设计方面有缺陷（比如包含大量静态方法），引入之后会影响到我们自身代码的可测试性。为了隔离设计上的缺陷，希望对外部系统提供的接口进行二次封装，抽象出更好的接口设计，这个时候就可以使用适配器模式了。
具体代码如下所示：
public class CD { // 这个类来自外部sdk，我们无权修改它的代码 public static void staticFunction1() { // ... } public void uglyNamingFunction2() { // ... } public void tooManyParamsFunction3(int paramA, int paramB, ...) { // ... } public void lowPerformanceFunction4() { // ... } } // 使用适配器模式进行重构 public interface ITarget { void function1(); void function2(); void fucntion3(ParamsWrapperDefinition paramsWrapper); void function4(); // ... } // 注意：适配器类的命名不一定非得末尾带Adaptor public class CDAdaptor extends CD implements ITarget { public void function1() { super.staticFunction1(); } public void function2() { super.uglyNamingFucntion2(); } public void function3(ParamsWrapperDefinition paramsWrapper) { super.tooManyParamsFunction3(paramsWrapper.getParamA(), ...); } public void function4() { // ...reimplement it... } }
统一多个类的接口设计
某个功能的实现依赖多个外部系统（或者说类）。通过适配器模式，将它们的接口适配为统一的接口定义，就可以使用多态的特性来复用代码逻辑。
假设我们的系统要对用户输入的文本内容做脱敏处理，为了提高过滤的召回率，引入了多款第三方敏感词过滤系统，依次对用户输入的内容进行过滤，过滤掉尽可能多的敏感词。但是，每个系统提供的过滤接口都是不同的。这就意味着没法复用一套逻辑来调用各个系统。这个时候就可以使用适配器模式，将所有系统的接口适配为统一的接口定义，这样可以复用调用敏感词过滤的代码。
具体代码如下：
import java.util.ArrayList; import java.util.List; public class ASensitiveWordsFilter { // A敏感词过滤系统提供的接口 // text是原始文本，函数输出用***替换敏感词之后的文本 public String filterSexyWords(String text) { // ... } public String filterPoliticalWords(String text) { // ... } } public class BSensitiveWordsFilter { // B敏感词过滤系统提供的接口 public String filter(String text) { // ... } } public class CSensitiveWordsFilter { // C敏感词过滤系统提供的接口 public String filter(String text, String mask) { // ... } } // 未使用适配器模式之前的代码：代码的可测试性、扩展性不好 public class RiskManagement { private ASensitiveWordsFilter aFilter = new ASensitiveWordsFilter(); private BSensitiveWordsFilter bFilter = new BSensitiveWordsFilter(); private CSensitiveWordsFilter cFilter = new CSensitiveWordsFilter(); public String filterSensitiveWords(String text) { String maskedText = aFilter.filterSexyWords(text); maskedText = aFilter.filterPoliticalWords(maskedText); maskedText = bFilter.filter(maskedText); maskedText = cFilter.filter(maskedText, "***"); return maskedText; } } // 使用适配器模式进行改造 public interface ISensitiveWordsFilter { // 统一接口定义 String filter(String text); } public class ASensitiveWordsFilterAdaptor implements ISensitiveWordsFilter { private ASensitiveWordsFilter aFilter; public String filter(String text) { String maskedText = aFilter.filterSexyWords(text); maskedText = aFilter.filterPoliticalWords(maskedText); return maskedText; } } // ...省略BSensitiveWordsFilterAdaptor、CSensitiveWordsFilterAdaptor... // 扩展性更好，更加符合开闭原则，如果添加一个新的敏感词过滤系统， // 这个类完全不需要改动；而且基于接口而非实现编程，代码的可测试性更好。 public class RiskManagement { private List<ISensitiveWordsFilter> filters = new ArrayList<>(); public void addSensitiveWordsFilter(ISensitiveWordsFilter filter) { filters.add(filter); } public String filterSensitiveWords(String text) { String maskedText = text; for (ISensitiveWordsFilter filter : filters) { maskedText = filter.filter(maskedText); } return maskedText; } }
替换依赖的外部系统
当我们把项目中依赖的一个外部系统替换为另一个外部系统的时候，利用适配器模式可以减少对代码的改动。具体的代码示例如下所示：
// 外部系统A
public interface IA {
void fa();
}
public class A implements IA {
public void fa() {
// ...
}
}
// 在我们的项目中，外部系统A的使用示例
public class Demo {
private IA a;
public Demo(IA a) {
this.a = a;
}
}
Demo d = new Demo(new A());
// 将外部系统A替换成外部系统B
public class BAdaptor implemnts IA {
private B b;
public BAdaptor(B b) {
this.b = b;
}
public void fa() {
b.fb();
}
}
// 借助BAdaptor，Demo的代码中，调用IA接口的地方都无需改动，
// 只需要将BAdaptor如下注入到Demo即可。
Demo d = new Demo(new BAdaptor(new B()));兼容老版本接口
在做版本升级的时候，对于一些要废弃的接口，不直接将其删除，而是暂时保留，并且标注为
@Deprecated，并将内部实现逻辑委托为新的接口实现。这样做的好处是，让使用它的项目有个过渡期，而不是强制进行代码修改。这也可以粗略地看作适配器模式的一个应用场景。JDK1.0 中包含一个遍历集合容器的类
Enumeration。JDK2.0 对这个类进行了重构，将它改名为Iterator类，并且对它的代码实现做了优化。但是考虑到如果将Enumeration直接从 JDK2.0 中删除，那使用 JDK1.0 的项目如果切换到 JDK2.0，代码就会编译不通过。为了避免这种情况的发生，必须把项目中所有使用到Enumeration的地方，都修改为使用 Iterator 才行。单独一个项目做
Enumeration到Iterator的替换，勉强还能接受。但是，使用 Java 开发的项目太多了，一次 JDK 的升级，导致所有的项目不做代码修改就会编译报错，这显然是不合理的。这就是我们经常说的不兼容升级。为了做到兼容使用低版本 JDK 的老代码，可以暂时保留Enumeration类，并将其实现替换为直接调用Itertor。代码示例如下所示：public class Collections { public static Emueration emumeration(final Collection c) { return new Enumeration() { Iterator i = c.iterator(); public boolean hasMoreElments() { return i.hashNext(); } public Object nextElement() { return i.next(): } } } }
适配不同格式的数据
前面讲到，适配器模式主要用于接口的适配，实际上，它还可以用在不同格式的数据之间的适配。比如，把从不同征信系统拉取的不同格式的征信数据，统一为相同的格式，以方便存储和使用。再比如，Java 中的Arrays.asList()也可以看作一种数据适配器，将数组类型的数据转化为集合容器类型。
List<String> stooges = Arrays.asList("Larry", "Moe", "Curly");剖析适配器模式在 Java 日志中的应用
Java 中有很多日志框架，在项目开发中，常常用它们来打印日志信息。其中，比较常用的有
log4j、logback，以及 JDK 提供的JUL(java.util.logging)和Apache的JCL(Jakarta Commons Logging)等。大部分日志框架都提供了相似的功能，比如按照不同级别（debug、info、warn、erro……）打印日志等，但它们却并没有实现统一的接口。这主要可能是历史的原因，它不像 JDBC 那样，一开始就制定了数据库操作的接口规范。
如果只是开发一个自己用的项目，那用什么日志框架都可以，
log4j、logback随便选一个就好。但是，如果开发的是一个集成到其他系统的组件、框架、类库等，那日志框架的选择就没那么随意了。比如，项目中用到的某个组件使用
log4j来打印日志，而我们项目本身使用的是logback。将组件引入到项目之后，我们的项目就相当于有了两套日志打印框架。每种日志框架都有自己特有的配置方式。所以，我们要针对每种日志框架编写不同的配置文件（比如，日志存储的文件地址、打印日志的格式）。如果引入多个组件，每个组件使用的日志框架都不一样，那日志本身的管理工作就变得非常复杂。所以，为了解决这个问题，需要统一日志打印框架。如果你是做 Java 开发的，那
Slf4j这个日志框架你肯定不陌生，它相当于 JDBC 规范，提供了一套打印日志的统一接口规范。不过，它只定义了接口，并没有提供具体的实现，需要配合其他日志框架（log4j、logback……）来使用。不仅如此，
Slf4j的出现晚于JUL、JCL、log4j等日志框架，所以，这些日志框架也不可能牺牲掉版本兼容性，将接口改造成符合Slf4j接口规范。Slf4j也事先考虑到了这个问题，所以，它不仅仅提供了统一的接口定义，还提供了针对不同日志框架的适配器。对不同日志框架的接口进行二次封装，适配成统一的Slf4j接口定义。具体的代码示例如下所示：// slf4j统一的接口定义 package org.slf4j; public interface Logger { public boolean isTraceEnabled(); public void trace(String msg); public void trace(String format, Object arg); public void trace(String format, Object arg1, Object arg2); public void trace(String format, Object[] argArray); public void trace(String msg, Throwable t); public boolean isDebugEnabled(); public void debug(String msg); public void debug(String format, Object arg); public void debug(String format, Object arg1, Object arg2); public void debug(String format, Object[] argArray); public void debug(String msg, Throwable t); // ...省略info、warn、error等一堆接口 } // log4j日志框架的适配器 // Log4jLoggerAdapter实现了LocationAwareLogger接口， // 其中LocationAwareLogger继承自Logger接口， // 也就相当于Log4jLoggerAdapter实现了Logger接口。 package org.slf4j.impl; public final class Log4jLoggerAdapter extends MarkerIgnoringBase implements LocationAwareLogger, Serializable { final transient org.apache.log4j.Logger logger; // log4j public boolean isDebugEnabled() { return logger.isDebugEnabled(); } public void debug(String msg) { logger.log(FQCN, Level.DEBUG, msg, null); } public void debug(String format, Object arg) { if (logger.isDebugEnabled()) { FormattingTuple ft = MessageFormatter.format(format, arg); logger.log(FQCN, Level.DEBUG, ft.getMessage(), ft.getThrowable()); } } public void debug(String format, Object arg1, Object arg2) { if (logger.isDebugEnabled()) { FormattingTuple ft = MessageFormatter.format(format, arg1, arg2); logger.log(FQCN, Level.DEBUG, ft.getMessage(), ft.getThrowable()); } } public void debug(String format, Object\[\] argArray) { if (logger.isDebugEnabled()) { FormattingTuple ft = MessageFormatter.arrayFormat(format, argArray); logger.log(FQCN, Level.DEBUG, ft.getMessage(), ft.getThrowable()); } } public void debug(String msg, Throwable t) { logger.log(FQCN, Level.DEBUG, msg, t); } // ...省略一堆接口的实现... }- 所以，在开发业务系统或者开发框架、组件的时候，我们统一使用
Slf4j提供的接口来编写打印日志的代码，具体使用哪种日志框架实现（log4j、logback……），是可以动态地指定的（使用 Java 的 SPI 技术），只需要将相应的SDK导入到项目中即可。 - 不过，如果一些老的项目没有使用
Slf4j，而是直接使用比如JCL来打印日志，那如果想要替换成其他日志框架，比如log4j，该怎么办呢？实际上，Slf4j不仅仅提供了从其他日志框架到Slf4j的适配器，还提供了反向适配器，也就是从Slf4j到其他日志框架的适配。可以先将JCL切换为Slf4j，然后再将Slf4j切换为log4j。经过两次适配器的转换，就成功将log4j切换为了logback。
- 所以，在开发业务系统或者开发框架、组件的时候，我们统一使用
代理、桥接、装饰器、适配器 4 种设计模式的区别
- 代理、桥接、装饰器、适配器，这 4 种模式是比较常用的结构型设计模式。它们的代码结构非常相似。笼统来说，它们都可以称为 Wrapper 模式，也就是通过 Wrapper 类二次封装原始类。
- 尽管代码结构相似，但这 4 种设计模式的用意完全不同，也就是说要解决的问题、应用场景不同，这也是它们的主要区别。
- 代理模式：在不改变原始类接口的条件下，为原始类定义一个代理类，主要目的是控制访问，而非加强功能，这是它跟装饰器模式最大的不同。
- 桥接模式：目的是将接口部分和实现部分分离，从而让它们可以较为容易、也相对独立地加以改变。
- 装饰器模式：在不改变原始类接口的情况下，对原始类功能进行增强，并且支持多个装饰器的嵌套使用。
- 适配器模式：是一种事后的补救策略。适配器提供跟原始类不同的接口，而代理模式、装饰器模式提供的都是跟原始类相同的接口。
