桥接模式有什么好处[关闭]

Question

当我想学习新东西时，我会问自己，如果我不学习那东西，我会失去什么。我要学习一些设计模式，一切都很好。但是当我到达Bridge Design Pattern 时，我遇到了问题。真的我无法想象什么时候使用这种设计模式。而且我知道 google 和 stackoverflow 中还有另一个链接，例如 this。

但是谁能这么说，如果我们忘记 Bridge Design Pattern 并跳过尝试这种模式，我们会失去什么？

Answer 1

桥接模式只是简单地注意到几个聚合的职责并将它们分开。我将使用 The Gang of Four (TGF) 的示例，因为我认为它非常好：

您有一个 Window 接口，它有两个子类：XWindow（基于 X Window Manager）和 PMWindow（基于 IBM 的 Presentation Manager (PM) Window Manager……我从未听说过）。

即：

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

桥的优点是抽象和实现是分离的。实现也在运行时动态变化，抽象和实现的可扩展性得到提高。

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