桥接模式的常见定义是抽象和实现的分离，实现抽象和实现的自由变化，在我看来，桥接模式的根本是实现同一个类或者同一个对象中存在着某种相互关联关系的元素可以自由变化，减少他们之间的耦合。接下来我就不写桥接模式的示例代码了，这些示例代码在网上已经有很多，大家可以去搜下，我们直接上干货。
2、AbsListView和Adapter的桥接模式
图1 Adapter中的桥接模式
AbsListView将Item展现在屏幕上时，调用自己的obtainView方法，obtainView方法又回去调用mAdapter的getView方法，这样，用户自定义的Item边可以展现出来。Android中显示列表数据时最终要的是getCount和getView这两个方法，这些重要的方法已经在接口Adapter中声明了，任何具体实现必须要实现这两个接口。从图1可以知道，ListAdapter接口继承了Adapter接口，阅读源码可以发现，ListAdapter接口在Adapter接口的基础上增加了两个方法：areAllItemsEnabled()和isEnabled(int position)。从图1可以看出，用户在展现列表数据时，可以自由定制个性化的adapter，只要adapter实现了ListAdapter中的接口即可，同时用户也可以自定义自己的列表实现，AbsListView在设计时被设计为抽象类，为列表数据的展示提供了各种各样的可能。这样，列表的子类在设计时可以不用考虑adapter的具体实现，adapter的具体实现也可以不用考虑列表子类的设计，列表子类和adapter可以根据需求自由变化，他们之间的耦合就大大降低。
可能这样简单的说明不足以表现这样设计的具体好处，可以想想，假设不用桥接模式，现在有了N种列表，每种列表都需要一种适配器，最后的结果就是系统中的适配器随着列表的增加而增加；还有另外一种可能，每种适配器都需要一种列表，如果不适用桥接，最后就需要N中列表来对应适配器。长此以往，最终的结果就是系统中列表和适配器的数目不断扩大，维护难度随着需求的增加而增加。
3、JDBC中的桥接模式
图2 JDBC
桥接模式比较经典的场景便是JDBC，在使用JDBC时，我们需要做的就是加载驱动，之后就是建立连接，连接成功后就可以对数据进行各种操作。如图3所示，JDBC定义好了每个数据库厂商在写驱动时时需要遵循的接口Driver，用户在加载驱动的时候，数据库厂商的驱动程序会主动向DriverManager注册，用户在加载MySql和Oracle数据驱动程序时，执行的代码分别如以下两段。
try {
java.sql.DriverManager.registerDriver(new Driver());
} catch (SQLException E) {
throw new RuntimeException("Can't register driver!");
}
{
defaultDriver = new oracle.jdbc.OracleDriver();
DriverManager.registerDriver(defaultDriver);
}
用户在加载完驱动后，对应驱动的信息就会在DriverManager以DriverInfo的形式进行保存。之后用户需要通过DriverManager获取数据库的连接，获取连接后用户就可以在数据库连接的基础上对数据库进行操作。
我一直在想如何在JDBC中区分桥接模式的抽象和实现，仔细分析后发现，JDBC中的桥接不能使用我们传统的桥接进行分析。JDBC的目标是要实现数据库厂商驱动和用户操作之间的解耦，目的是为了防止驱动程序对用户的应用产生影响。DriverManager作为桥梁，屏蔽了用户应用和驱动程序之间的联系，DriverManager需要做的就是管理驱动，根据需要向用户提供数据库的链接，用户在数据库链接的基础上开发自己的个性化应用即可。因此，JDBC中的桥接，实现了用户应用和驱动程序之间的自由变化。
4、桥接模式的扩展
前面几段的分析可以发现，桥接模式的根本是实现有依赖关系的两个元素可以自由变化，因此，不需要可以关注是否为抽象和实现之间的自由变化，只要两个元素之间可以自由变化应该都是桥接。
图3 桥接模式的扩展
如图4所示，Dimension2依赖Dimension1，在传统的设计中Dimension1要求是一个接口，但在实际中，Dimension1完全可以是一个抽象类。在使用时，Dimension2和Dimension1可以自由变化。
这个扩展主要是为了说明桥接模式并不一定要是那种抽象与实现的分离，还有可能是抽象与抽象的分离，甚至还有可能是其他形式的分离，在分析桥接模式时，我们不应该拘泥于抽象与实现或者抽象与抽象，只要是有依赖的东西可以在自己的维度上自由变化我们都可以称之为桥接。
网友评论