抽象与实现
抽象不应该依赖于实现细节,实现细节应该依赖于抽象。
动机:
事实上由于Tank类型的固有逻辑,使得Tank类型具有了两个变化的维度——一个变化的维度为“平台的变化”,一个变化的维度为“型号的变化”。
如何应对这种“多维度的变化”?如何利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化,而不引入额外的复杂度?
意图:
将抽象部分与实现部分分离,使它们都可以独立地变化。
Bridge模式的几个要点:
l Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象(Tank的型号)和实现(不同的平台)可以沿着各自的维度来变化。
l 所谓抽象和实现沿着各自维度的变化,即“子类化”它们,比如不同的Tank型号子类,和不同的平台子类。得到各个子类之后,便可以任意组合它们,从而获得不同平台上的不同型号。
l Bridge模式有时候类似于多继承方案,但是多继承方案往往违背单一职责原则(即一个类只有一个变化的原因),复用性比较差。Bridge模式是比多继承方案更好的解决方法。
l Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,并不一定要使用Bridge模式。
桥接接口
Bridger.cs代码示例:













Product.cs代码示例:
































VisList.cs代码示例:















ListBridge.cs代码示例:























事件代码:





























ProductList.cs代码示例:



























GridList.cs代码示例:


































扩展Bridge
Product.cs代码示例:
































SortBridge.cs代码示例:


































TreeList.cs代码示例:


























TreeAdapter.cs代码示例:








































桥接模式的效果:
1. 桥接模式可以保持客户端程序的接口不变,而允许读者修改显示类或要使用的类。这可以防止重新编译一系列复杂的用户接口模式,而只需要重新编译Bridge和实际的最终显示类。
2. 可以分别扩展实现类和Bridge类,二者之间通常不会有相互作用。
3. 对客户端程序很容易隐藏实现细节。