Java的JDBC和桥接模式详解 Java的JDBC和桥接模式详解

本文参考
桥接模式的定义与特点

定义：
优点：
缺点：

桥接模式的基本结构

桥接模式的应用场景

JDBC源码剖析

Class.forName()方法
com.mysql.cj.jdbc.Driver类
引申：
DriverManager类
Connection接口

源码类图

模式体现

其它观点二：JDBC采用的是策略模式而不是桥接模式

其它观点三：变化的维度一个是平台，另一个是数据库

其它观点四：变化的维度一个是客户端应用系统，另一个是数据库

新的观点五：变化的维度一个是Driver，一个是Connection

总结

本文参考网上对于JDBC与桥接模式的理解各有不同，在这片文章里提出的是我个人对于二者的理解，本文参考的其它博文如下：
https://www.jb51.net/article/217763.htm
https://www.jb51.net/article/112714.htm
https://www.jb51.net/article/137835.htm
http://edu.jb51.net/design-pattern/design-pattern-bridge.html

桥接模式的定义与特点
定义：
将抽象与实现分离，使它们可以独立变化。它是用组合/聚合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。例如针对一个图形，我们可以设计颜色和形状两个变化维度

优点：
由于抽象与实现分离，所以扩展能力强；实现细节对客户透明

缺点：
由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，这增加了系统的理解与设计难度

桥接模式的基本结构 Abstraction — 抽象化角色：
定义抽象的接口，包含一个对实现化角色的引用
Refined Abstraciotn — 扩展抽象化角色：
抽象化角色的子类，实现父类中的业务方法，并通过组合/聚合关系调用实现化角色中的业务方法
Implementor — 实现化角色：
定义具体行为、具体特征的应用接口，供扩展抽象化角色使用
Concrete Implemetor — 具体实现化角色：
实现化角色的具体实现
基本的模式结构类图如下：

文章图片

桥接模式的应用场景

当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时
当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时
当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时

JDBC源码剖析在不使用Spring、Hibernate等第三方库的情况下，直接通过原生JDBC API连接MySQL数据库，则有如下示例代码：

Class.forName("com.mysql.cj.jdbc.Driver"); Connection conn = DriverManager.getConnection("jdbc:mysql://:/");

短短两行代码难以看出桥接模式的结构，下面先对源码进行一定的分析，理解各个类和接口之间的关系

Class.forName()方法
该方法将返回与给定字符串名的类或接口相关联的java.lang.Class类对象，用于在程序运行时的某个时刻，由客户端调用，动态加载该类或该接口到当前线程中

Returns the Class object associated with the class or interface with the given string name.
Given the fully qualified name for a class or interface this method attempts to locate, load, and link the class or interface.

若Class.forName()加载的是一个类，也会执行类中包含的static { } 静态代码段

com.mysql.cj.jdbc.Driver类
MySQL将具体的java.sql.Driver接口的实现放到了NonRegisteringDriver中，com.mysql.cj.jdbc.Driver类仅包含一段静态代码，具体类图如下：

文章图片

其中最关键的是静态代码段中的 DriverManager.registerDriver(new Driver()) ，它会在客户端调用Class.forName()方法加载com.mysql.cj.jdbc.Driver类的同时被执行，Driver类自身的一个实例被注册到DriverManager（即保存到DriverManager的静态字段registeredDrivers内），注册过程的源码如下：

public static synchronized void registerDriver(java.sql.Driver driver, DriverAction da)throws SQLException {/* Register the driver if it has not already been added to our list */if(driver != null) {registeredDrivers.addIfAbsent(new DriverInfo(driver, da)); } else {// This is for compatibility with the original DriverManagerthrow new NullPointerException(); }println("registerDriver: " + driver); }

registeredDrivers静态字段的类型是实现了List接口的CopyOnWriteArrayList类，它能够保存进一步封装java.sql.Driver接口的DriverInfo类实例，DriverInfo类的声明代码如下：

class DriverInfo {final Driver driver; DriverAction da; DriverInfo(Driver driver, DriverAction action) {this.driver = driver; da = action; }// ……}

引申：
DriverInfo还包装了DriverAction，DriverAction会在Driver被取消注册时被调用，DriverAction的源码注释如下：

The JDBC driver's static initialization block must call DriverManager.registerDriver(Driver, DriverAction) in order to inform DriverManager which DriverAction implementation to call when the JDBC driver is de-registered.

MySQL的Driver在向DriverManager进行注册时，DriverAction被设置为null

DriverManager类
由上面的分析可得，Class.forName()方法调用后，com.mysql.cj.jdbc.Driver类被加载，并执行static { } 静态代码段，将com.mysql.cj.jdbc.Driver类实例注册到DriverManager中。然后，客户端会调用DriverManager.getConnection()方法获取一个Connection数据库连接实例，该方法的部分源码如下：

private static Connection getConnection(String url, java.util.Properties info, Class caller) throws SQLException {// ……for(DriverInfo aDriver : registeredDrivers) {// If the caller does not have permission to load the driver then// skip it.if(isDriverAllowed(aDriver.driver, callerCL)) {try {println(" trying " + aDriver.driver.getClass().getName()); Connection con = aDriver.driver.connect(url, info); if (con != null) {// Success!println("getConnection returning " + aDriver.driver.getClass().getName()); return (con); }} catch (SQLException ex) {if (reason == null) {reason = ex; }}} else {println(" skipping: " + aDriver.getClass().getName()); }}// ……}

DriverManager.getConnection()方法会遍历registeredDrivers静态字段，获取字段内保存的每一个Driver来尝试响应客户端的数据库连接请求，若所有Driver都连接数据库失败，则提示连接失败信息

Connection接口
【Java的JDBC和桥接模式详解】Connection代表和特定数据库的连接会话，能够执行SQL语句并在连接的上下文中返回执行结果。

A connection (session) with a specific database. SQL statements are executed and results are returned within the context of a connection.

因此，DriverManager.getConnection()方法返回的Connection数据库连接实例根据不同的数据库有不同的实现，MySQL的Connection接口实现关系如下：

文章图片

源码类图根据源码的分析，绘制类图如下：

文章图片

对Driver和Connection进行抽象，绘制类图如下：

文章图片

模式体现桥接模式通过组合/聚合关系代替继承关系，实现抽象化和实现化部分的解耦。以上述JDBC在MySQL中的简略类图为例，抽象化部分有Driver接口和Connection接口，实现化部分有DriverManager。对于不同的数据库，Driver接口和Connection接口都有自己独特的实现类
但是，和Driver接口不同的是，Connection接口与DriverManager类的关系只是联系较弱的依赖关系，并不符合桥接模式的定义和特点。因此，在考虑桥接模式的情况下，可以再次将类图进行简化：

文章图片

最后，我们将其它数据库的Driver接口实现也考虑在内，绘制类图如下：

文章图片

桥接模式中的实现化(Implementor)角色对应上图的Driver接口，具体实现化(Concrete Implementor)角色对应MysqlDriver、OracleDriver和MariadbDriver，扩展抽象化 (Refined Abstraction)角色对应DriverManager，不具有抽象化(Abstraction)角色作为扩展抽象化角色的父类
桥接模式的主要应用场景是某个类存在两个独立变化的维度，且这两个维度都需要进行扩展，而现在仅有Driver一个变化维度，DriverManager没有抽象化父类，它本身也没有任何子类，因此我认为，在JDBC中，是一种简化的桥接模式 —— 观点一。
倘若JDBC针对Connection接口的设计不是将它作为Driver和DriverManager的"依赖"来处理，而是也作为一个变化的维度加入到桥接模式，或许能够更好地体现JDBC对桥接模式的实现，一种"假想"的桥接模式如下：

文章图片

其它观点二：JDBC采用的是策略模式而不是桥接模式问题源自知乎，但是没有任何人做出解答，因为这确实和策略模式十分相似，如果把桥接模式的抽象部分简化来看，不去设计Abstraction，也就是用Refined Abstraction代替Abstraction，那么就类似于策略模式的Context来使用接口的对象
但是，桥接模式和策略模式的目的是不一样的，策略模式属于对象行为模式（描述对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责），它的目的是封装一系列的算法，使得算法可以相互替代，并在程序运行的不同时刻选择合适的算法。而桥接模式属于对象结构模式（描述如何将对象按某种布局组成更大的结构），它的目的是将抽象与实现分离，使它们可以独立变化
因此，从设计的目的来看，JDBC采用的并不是策略模式，在一段程序中数据库驱动并不存在频繁地相互替换

其它观点三：变化的维度一个是平台，另一个是数据库这是我认同的一个观点，引用原文的话

变的是平台和数据库，平台在jvm这个层面就解决了，因为所有操作系统java基本都会提供对应JDK，这也是"Once Write，Run AnyWhere"的原因。而数据库则是依托公司的具体实现，各个公司都提供对应的Driver类，我用DriverManager类进行懒加载

考虑数据库的实际应用场景，我们可能在不同的操作系统上使用不同的数据库，但是JVM的平台无关性使得我们不再有操作系统层面上的变化。假设不存在JVM，那么不同的客户端加载和运行数据库驱动程序的代码自然也各有不同，即DriverManager会因操作系统的变化而变化，不同的操作系统可以有不同的注册Driver的方式
不过因为存在JVM，我们现在不再有"平台"这一变化维度了

其它观点四：变化的维度一个是客户端应用系统，另一个是数据库一个比较独特的观点，引用原文的话

应用系统作为一个等级结构，与JDBC驱动器这个等级结构是相对独立的，它们之间没有静态的强关联。应用系统通过委派与JDBC驱动器相互作用，这是一个桥梁模式的例子。

原文笔者不认为DriverManager作为Refined Abstraction角色存在，而是视作两个变化维度之间的一个"过渡"，原本的"桥"是Abstraction和Implementor之间的组合/聚合关系，而现在DriverManager类本身成为了"桥"，可以看作是桥梁模式的一个变体

新的观点五：变化的维度一个是Driver，一个是Connection 如果从观点四的原文笔者的角度看，把DriverManager类本身作为"桥"，那么我们还可以提出一种新的观点，绘制类图如下：