Bridge Pattern的好处是什么？

Question

当我想学习新东西的时候，我会问自己，当我没有学到那些东西时，我失去了什么。我将学习一些设计模式，一切都很好。但是当我到达Bridge Design Pattern时，我陷入了困境。真的我无法想象何时使用这种设计模式。我知道google和stackoverflow中还有其他链接，例如this。

但任何人都可以说，如果我们忘记了Bridge Design Pattern并跳过尝试这种模式，我们会失去什么？

Answer 1

Bridge模式只是注意到几个融合的责任并将它们分开。我将使用The Gang of Four（TGF）的例子，因为我认为它是一个非常好的例子：

你有一个Window接口，有两个子类：XWindow（基于X Window Manager）和PMWindow（基于IBM的Presentation Manager（PM）窗口管理器......我从未听说过）。

即：

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 ++的多重继承，您可以将任何实现静态地耦合到它们的窗口系统。换句话说，你拥有与非桥模式相同数量的类型，但它们可能是空类，你当然可以通过抽象来引用它们，这使得它很容易被消费。

Answer 2

桥梁的优点是抽象和实现是分离的。实现也在运行时动态更改，抽象和实现的可扩展性得到改善。

通过在抽象的生成中指定参数，可以选择实现也完全隐藏客户端的实现。可以避免课程数量的大幅增加。