当我想学习新东西时,我会问自己,当我不学习那东西时,我失去了什么。我要学习一些设计模式,一切都很好。但是当我到达桥接设计模式时,我遇到了问题。真的我无法想象什么时候使用这种设计模式。而且我知道在 google 和 stackoverflow 中还有另一个链接是这样的。
但是谁能这么说,如果我们忘记Bridge Design Pattern
并跳过尝试这种模式,我们会失去什么?
桥接模式只是简单地注意到几个聚合的职责并将它们分开。我将使用 The Gang of Four (TGF) 的示例,因为我认为它非常好:
您有一个 Window 界面,有两个子类:XWindow(基于 X Window Manager)和 PMWindow(基于 IBM 的 Presentation Manager (PM) Window Manager……我从未听说过)。
IE:
interface Window {}
class XWindow : Window {}
class PMWindow : Window {}
继续使用我们的传统继承方法的问题在于,如果您将 Window 专门用于其平台依赖性以外的方面(即,您有一些与您创建要支持的继承树正交的责任),您需要使用桥模式,否则您的类层次结构将几何深度增长。我认为将桥接视为继承和组合的组合的好方法。
可以说是很啰嗦了。回到 TGF 的例子:如果你想要一个 IconWindow 和一个 TransientWindow(有点像玻璃窗格)。“Icon vs Transient”和“PM vs X”的概念是两个正交的概念,但它们都试图在同一个继承树上。如果不使用桥接模式,您需要做的是创建两个继承自第一个接口的新接口,以及它们下面的一系列类:
interface Window {}
class XWindow : Window {}
class PMWindow : Window {}
interface IconWindow : Window {}
class XIconWindow : XWindow, IconWindow {}
class PMIconWindow : PMWindow, IconWindow {}
interface TransientWindow : Window {}
class XTransientWIndow : XWindow, TransientWindow {}
class PMTransientWindow : PMWindow, TransientWindow {}
使用桥接模式,您可以将这两个职责分离到两个继承树上:
interface Window {}
class IconWindow : Window {} //this class...
class TransientWindow : Window {} //and this one will keep a private reference to aWindowImp
interface WindowImp: Window {}
class XWindowImp : WindowImp {}
class PMWindowImp : WindowImp {}
更干净,更好的职责分离,更容易编写和使用!
我相信这个设计问题和桥对象树的奇怪之处实际上是推动 Scala 中 Mix-ins 设计的一些问题。使用 C++ 的多重继承,您可以将任何实现静态耦合到它们的窗口系统。换句话说,您将拥有与非桥接模式相同数量的类型,但它们可能是空类,您当然可以通过抽象来引用它们,这使得使用起来相当容易。
桥的优点是抽象和实现是分离的。实现也在运行时动态改变,抽象和实现的可扩展性得到改善。
通过在抽象的生成中指定一个参数,实现也可以选择,因为客户端的实现是完全隐藏的。可以避免类数量的大幅增加。