本文參考

網(wǎng)上對于JDBC與橋接模式的理解各有不同，在這片文章里提出的是我個人對于二者的理解，本文參考的其它博文如下：

http://www.fzitv.net/article/217763.htm

http://www.fzitv.net/article/112714.htm

http://www.fzitv.net/article/137835.htm

http://edu.jb51.net/design-pattern/design-pattern-bridge.html

橋接模式的定義與特點

定義：

將抽象與實現(xiàn)分離，使它們可以獨立變化。它是用組合/聚合關(guān)系代替繼承關(guān)系來實現(xiàn)，從而降低了抽象和實現(xiàn)這兩個可變維度的耦合度。例如針對一個圖形，我們可以設(shè)計顏色和形狀兩個變化維度

優(yōu)點：

由于抽象與實現(xiàn)分離，所以擴展能力強；實現(xiàn)細(xì)節(jié)對客戶透明

缺點：

由于聚合關(guān)系建立在抽象層，要求開發(fā)者針對抽象化進(jìn)行設(shè)計與編程，這增加了系統(tǒng)的理解與設(shè)計難度

橋接模式的基本結(jié)構(gòu)

Abstraction — 抽象化角色：

定義抽象的接口，包含一個對實現(xiàn)化角色的引用

Refined Abstraciotn — 擴展抽象化角色：

抽象化角色的子類，實現(xiàn)父類中的業(yè)務(wù)方法，并通過組合/聚合關(guān)系調(diào)用實現(xiàn)化角色中的業(yè)務(wù)方法

Implementor — 實現(xiàn)化角色：

定義具體行為、具體特征的應(yīng)用接口，供擴展抽象化角色使用

Concrete Implemetor — 具體實現(xiàn)化角色：

實現(xiàn)化角色的具體實現(xiàn)

基本的模式結(jié)構(gòu)類圖如下：

橋接模式的應(yīng)用場景

• 當(dāng)一個類存在兩個獨立變化的維度，且這兩個維度都需要進(jìn)行擴展時
• 當(dāng)一個系統(tǒng)不希望使用繼承或因為多層次繼承導(dǎo)致系統(tǒng)類的個數(shù)急劇增加時
• 當(dāng)一個系統(tǒng)需要在構(gòu)件的抽象化角色和具體化角色之間增加更多的靈活性時

JDBC源碼剖析

在不使用Spring、Hibernate等第三方庫的情況下，直接通過原生JDBC API連接MySQL數(shù)據(jù)庫，則有如下示例代碼：

Class.forName("com.mysql.cj.jdbc.Driver");
Connection conn = DriverManager.getConnection("jdbc:mysql://<host>:<port>/<database>");

短短兩行代碼難以看出橋接模式的結(jié)構(gòu)，下面先對源碼進(jìn)行一定的分析，理解各個類和接口之間的關(guān)系

Class.forName()方法

該方法將返回與給定字符串名的類或接口相關(guān)聯(lián)的java.lang.Class類對象，用于在程序運行時的某個時刻，由客戶端調(diào)用，動態(tài)加載該類或該接口到當(dāng)前線程中

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()加載的是一個類，也會執(zhí)行類中包含的static { } 靜態(tài)代碼段

com.mysql.cj.jdbc.Driver類

MySQL將具體的java.sql.Driver接口的實現(xiàn)放到了NonRegisteringDriver中，com.mysql.cj.jdbc.Driver類僅包含一段靜態(tài)代碼，具體類圖如下：

其中最關(guān)鍵的是靜態(tài)代碼段中的 DriverManager.registerDriver(new Driver()) ，它會在客戶端調(diào)用Class.forName()方法加載com.mysql.cj.jdbc.Driver類的同時被執(zhí)行，Driver類自身的一個實例被注冊到DriverManager（即保存到DriverManager的靜態(tài)字段registeredDrivers內(nèi)），注冊過程的源碼如下：

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 DriverManager
    throw new NullPointerException();
  }
  println("registerDriver: " + driver);
}

registeredDrivers靜態(tài)字段的類型是實現(xiàn)了List接口的CopyOnWriteArrayList類，它能夠保存進(jìn)一步封裝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被取消注冊時被調(diào)用，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進(jìn)行注冊時，DriverAction被設(shè)置為null

DriverManager類

由上面的分析可得，Class.forName()方法調(diào)用后，com.mysql.cj.jdbc.Driver類被加載，并執(zhí)行static { } 靜態(tài)代碼段，將com.mysql.cj.jdbc.Driver類實例注冊到DriverManager中。然后，客戶端會調(diào)用DriverManager.getConnection()方法獲取一個Connection數(shù)據(jù)庫連接實例，該方法的部分源碼如下：

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靜態(tài)字段，獲取字段內(nèi)保存的每一個Driver來嘗試響應(yīng)客戶端的數(shù)據(jù)庫連接請求，若所有Driver都連接數(shù)據(jù)庫失敗，則提示連接失敗信息

Connection接口

Connection代表和特定數(shù)據(jù)庫的連接會話，能夠執(zhí)行SQL語句并在連接的上下文中返回執(zhí)行結(jié)果。

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

因此，DriverManager.getConnection()方法返回的Connection數(shù)據(jù)庫連接實例根據(jù)不同的數(shù)據(jù)庫有不同的實現(xiàn)，MySQL的Connection接口實現(xiàn)關(guān)系如下：

源碼類圖

根據(jù)源碼的分析，繪制類圖如下：

對Driver和Connection進(jìn)行抽象，繪制類圖如下：

模式體現(xiàn)

橋接模式通過組合/聚合關(guān)系代替繼承關(guān)系，實現(xiàn)抽象化和實現(xiàn)化部分的解耦。以上述JDBC在MySQL中的簡略類圖為例，抽象化部分有Driver接口和Connection接口，實現(xiàn)化部分有DriverManager。對于不同的數(shù)據(jù)庫，Driver接口和Connection接口都有自己獨特的實現(xiàn)類

但是，和Driver接口不同的是，Connection接口與DriverManager類的關(guān)系只是聯(lián)系較弱的依賴關(guān)系，并不符合橋接模式的定義和特點。因此，在考慮橋接模式的情況下，可以再次將類圖進(jìn)行簡化：

最后，我們將其它數(shù)據(jù)庫的Driver接口實現(xiàn)也考慮在內(nèi)，繪制類圖如下：

橋接模式中的實現(xiàn)化(Implementor)角色對應(yīng)上圖的Driver接口，具體實現(xiàn)化(Concrete Implementor)角色對應(yīng)MysqlDriver、OracleDriver和MariadbDriver，擴展抽象化 (Refined Abstraction)角色對應(yīng)DriverManager，不具有抽象化(Abstraction)角色作為擴展抽象化角色的父類

橋接模式的主要應(yīng)用場景是某個類存在兩個獨立變化的維度，且這兩個維度都需要進(jìn)行擴展，而現(xiàn)在僅有Driver一個變化維度，DriverManager沒有抽象化父類，它本身也沒有任何子類，因此我認(rèn)為，在JDBC中，是一種簡化的橋接模式 —— 觀點一。

倘若JDBC針對Connection接口的設(shè)計不是將它作為Driver和DriverManager的"依賴"來處理，而是也作為一個變化的維度加入到橋接模式，或許能夠更好地體現(xiàn)JDBC對橋接模式的實現(xiàn)，一種"假想"的橋接模式如下：

其它觀點二：JDBC采用的是策略模式而不是橋接模式

問題源自知乎，但是沒有任何人做出解答，因為這確實和策略模式十分相似，如果把橋接模式的抽象部分簡化來看，不去設(shè)計Abstraction，也就是用Refined Abstraction代替Abstraction，那么就類似于策略模式的Context來使用接口的對象

但是，橋接模式和策略模式的目的是不一樣的，策略模式屬于對象行為模式（描述對象之間怎樣相互協(xié)作共同完成單個對象都無法單獨完成的任務(wù)，以及怎樣分配職責(zé)），它的目的是封裝一系列的算法，使得算法可以相互替代，并在程序運行的不同時刻選擇合適的算法。而橋接模式屬于對象結(jié)構(gòu)模式（描述如何將對象按某種布局組成更大的結(jié)構(gòu)），它的目的是將抽象與實現(xiàn)分離，使它們可以獨立變化

因此，從設(shè)計的目的來看，JDBC采用的并不是策略模式，在一段程序中數(shù)據(jù)庫驅(qū)動并不存在頻繁地相互替換

其它觀點三：變化的維度一個是平臺，另一個是數(shù)據(jù)庫

這是我認(rèn)同的一個觀點，引用原文的話

變的是平臺和數(shù)據(jù)庫，平臺在jvm這個層面就解決了，因為所有操作系統(tǒng)java基本都會提供對應(yīng)JDK，這也是"Once Write，Run AnyWhere"的原因。而數(shù)據(jù)庫則是依托公司的具體實現(xiàn)，各個公司都提供對應(yīng)的Driver類，我用DriverManager類進(jìn)行懶加載

考慮數(shù)據(jù)庫的實際應(yīng)用場景，我們可能在不同的操作系統(tǒng)上使用不同的數(shù)據(jù)庫，但是JVM的平臺無關(guān)性使得我們不再有操作系統(tǒng)層面上的變化。假設(shè)不存在JVM，那么不同的客戶端加載和運行數(shù)據(jù)庫驅(qū)動程序的代碼自然也各有不同，即DriverManager會因操作系統(tǒng)的變化而變化，不同的操作系統(tǒng)可以有不同的注冊Driver的方式

不過因為存在JVM，我們現(xiàn)在不再有"平臺"這一變化維度了

其它觀點四：變化的維度一個是客戶端應(yīng)用系統(tǒng)，另一個是數(shù)據(jù)庫

一個比較獨特的觀點，引用原文的話

應(yīng)用系統(tǒng)作為一個等級結(jié)構(gòu)，與JDBC驅(qū)動器這個等級結(jié)構(gòu)是相對獨立的，它們之間沒有靜態(tài)的強關(guān)聯(lián)。應(yīng)用系統(tǒng)通過委派與JDBC驅(qū)動器相互作用，這是一個橋梁模式的例子。

原文筆者不認(rèn)為DriverManager作為Refined Abstraction角色存在，而是視作兩個變化維度之間的一個"過渡"，原本的"橋"是Abstraction和Implementor之間的組合/聚合關(guān)系，而現(xiàn)在DriverManager類本身成為了"橋"，可以看作是橋梁模式的一個變體

新的觀點五：變化的維度一個是Driver，一個是Connection

如果從觀點四的原文筆者的角度看，把DriverManager類本身作為"橋"，那么我們還可以提出一種新的觀點，繪制類圖如下：

總結(jié)

本篇文章就到這里了，希望能夠給你帶來幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容!

最新評論