模式说明

桥接模式的解释，就是“抽象与实现解耦，使两者可以独立变化”，这种模式是严格遵守了组合优于继承原则。那么，讲解桥接模式之前，我们先来看看继承会有哪些缺点。如果一个类不是专门为了继承而设计则不应该被继承，这是为什么呢？因为该类的方法有可能会随时发生改变，有可能是添加 final 或改名等，都会使得子类无法使用。又或者父类增加了一个与子类方法名相同但返回类型不同的方法，会致使编译错误。

并不是说继承一无是处，继承非常强大，但很多时候会违反封装性，这是因为父类可能会不断改变直接影响子类的功能实现。如果子类和父类存在 “is-a” 关系，这样才值得使用继承，就如模板设计模式。

而桥接模式则是为了解耦继承中的抽象和实现，从而避免类继承所带来的缺点，且不需受到继承的约束。而具体的实现也非常简单就是通过组合及依赖注入的方式完成，难点就在于识别出抽象和实现。

应用场景

通过桥接模式将继承关系拆解，可以参考如下图 1 所示。

图 1

桥接模式能够使程序更容易被扩展，而且不受继承的约束。以 Java 中的 InputStreamReader 为例，这个是典型的桥接模式设计，现在参考它的实现方式进行扩展，将字节流转为 Base64 及 Hex 文本，相应的增加桥接类 Base64Reader / HexReader。桥接模式能够使得 InputStream 不需要继承类或实现接口的方式提供额外的字节流转字符流的功能，极大限度的增加其可扩展性，类之间的关系如下图 2 所示。

图 2

代码实现

字符流扩展

现在我们通过代码实现 Base64Reader / HexRerader，将字节流转为 Base64 / Hex 字符串，代码如下。

public class Base64Reader extends Reader {
    private InputStream in;
    public Base64Reader(InputStream in) {
        super(in);
        this.in = in;
    }
    @Override
    public int read(char[] cbuf, int off, int len) throws IOException {
        // 3 bytes -> 4 chars
        return ...;
    }
    @Override
    public void close() throws IOException {
        in.close();
    }
}

public class HexReader extends Reader {
    private InputStream in;
    public HexReader(InputStream in) {
        super(in);
        this.in = in;
    }
    @Override
    public int read(char[] cbuf, int off, int len) throws IOException {
        // 1 byte -> 2 chars
        return ...;
    }
    @Override
    public void close() throws IOException {
        in.close();
    }
}

项目实战

再来看一个实际的项目，要实现的功能是将 DSL 风格的代码转换为 SQL，主要是为了解决重复编写 JDBC 代码，以 Java 代码风格代替直接拼写 SQL 语句，代码片段如下所示。

select().from("t_table").where().eq("name", "jsql").execQuery();
// SQL: select * from t_table where name=?
// values: ["jsql"]

刚开始设计了一个 Builder 接口，其中接口就有非常多的方法，如 select() / update() / insert() / delete() / where() / and() / or() / eq()… 还有很多其他方法。为了区分 select() / update() / insert() / delete() 四种类型，于是抽象出模板类 AbstractBuilder，分别创建 SelectBuilder / UpdateBuilder / InsertBuilder / DeleteBuilder 继承 AbstractBuilder，以保证每个操作的合法性，如 update / insert / delete 不能使用 forUpdate() 操作，至今类的关系会是如下图 3 所示。

图 3

上面的需求中并没有提及使用哪种数据库，要知道 MySQL / Oracle 的 SQL 实现就不一样，虽然大部分相同，但都会带有自个的个性 SQL 特性，现在我们需要支持不同的数据库，现在将 SelectBuilder / UpdateBuilder / InsertBuilder / DeleteBuilder 继承具体的数据库 Builder，如下图 4 所示。

图 4_

上图 4 的问题是继承的类实在太多了，简直是继承爆炸，而且只是部分的数据库，还有其他的数据库待实现。现在面临的问题就是如何减少这种继承的类数量及降低继承的层次关系。为了解耦继承关系，抽离实现和抽象，这不就是桥接模式要做的事情吗，于是将上图 4 以桥接模式重新设计后，将得到下图 5 的关系所示。

图 5

现在抽象出 Builder 负责构造 SQL，而 Dialect（方言）则是根据不同的数据库实现，从而解决因不同数据库之间的差异引起的类继承爆炸问题。Builder 属于抽象（相当于所谓的桥），Dialect 对应的是实现，经过桥接方式的设计，将变化部分提炼到 Dialect 中处理。以下是针对上述实现的代码片段。

public abstract class AbstractBuilder implements Builder {
    public AbstractBuilder(Dialect dialect) {
        this.dialect = dialect;
        // ...
    }
    @Override
    public Builder joinUsing(String tableName, String... columns) {
        // 并不是所有数据库都支持 join <TABLE_NAME> using 语法
        if (!dialect.supportJoinUsing()) {
            throw new UnsupportedOperationException();
        }
        // join <tableName> using (ref_id)
        joinUsing("join", tableName, columns);
        return this;
    }
    // ... ...
}

public interface Dialect {
    boolean supportJoinUsing();
    // ...
}
public class MySQLDialect implements Dialect {
    public boolean supportJoinUsing() {
        return true;
    }
    // ...
}
public class OrableDialect implements Dialect {
    public boolean supportJoinUsing() {
        return true;
    }
    // ...
}

Dialect dialect = new MySQLDialect();
Builder builder = new SelectBuilder(dialect);
builder.select().from("t_table").where().eq("name", "jsql").execQuery();

桥接模式 | Bridge

模式说明

应用场景

代码实现

字符流扩展

项目实战