Question

我在某种程度上理解桥梁模式。我理解接口和实现的分离。它使用 implementsor 类，就像一个插件，它保存派生类实现的实际逻辑。

但有人可以解释它如何允许接口和派生独立发展吗？如果我想在接口中添加一个新方法，则必须在派生类中实现它，这将修改它。

其次，当需要新对象时，必须修改客户端代码以设置新的实现者。

Answer 1

是的，Bridge模式的目的是将抽象（即接口）与实现分离，让它们独立变化。在实践中，我们的想法是使用两个单独的层次结构而不是经典的单一层次结构。

我们举个例子。假设您有一个 Window 抽象，并且需要为每个支持的平台创建一个专门用于 Window 的IconWindow子类。

使用单一层次结构，您将获得：

                     Window
                       |--------------...
                   IconWindow
                       |
   -----------------------------------------------...
   |                   |                   |
XIconWindow       MSIconWindow      OSXIconWindow

这种结构非常不方便，因为：

如果要添加专门用于 Window 的新子类（例如，BitmapWindow），则必须为每个支持的平台创建一个子类（即本例中的三个子类）。
如果要添加支持的平台，则必须为每个现有专业化添加新的子类。

因此，最好通过：

来解耦两个层次结构

             imp
      Window--------------------------> WindowImp
         |                                  |
    -----------....            ---------------------------------
    |                          |              |                |
IconWindow                XWindowImp      MSWindowImp    OSXWindowImp

Window 和 WindowImp 是接口。 IconWindow使用 Window 提供的方法。反过来， Window 会调用imp。

上的相关方法

Window 和 WindowImp 之间的关系称为 Bridge 。

实施例： IconWindow :: DrawBorder（）使用Window :: DrawRect（），它调用imp-＆gt; DevDrawLine（），它在 WindowImp 中声明并在具体子类中定义（例如，在类XWindowImp中）。 / p>

我的建议是阅读包含上述示例的书籍“设计模式 - 可重用面向对象软件的元素”（http://en.wikipedia.org/wiki/Design_Patterns）。

Answer 2

我认为Java JDBC API是说明Bridge Design Pattern用户的最佳示例。客户端使用抽象（JDBC API）而不必担心不同SQL供应商提供的实现（MYSQL，Oracle等）。

进一步说明您有EmployeeDAOImpl，它使用save，update，delete方法实现EmployeeDAO接口。现在，这个EmployeeDAOImpl将使用JDBC API（抽象）来执行CRUD操作，而不必担心使用的数据库。 EmployeeDAOImpl唯一需要的是加载驱动程序的URL。

现在关键是，EmployeeDAOImpl和其他DAO的层次结构可以独立变化。他们不必担心JDBI API抽象的实现。

Answer 3

桥牌模式：

将抽象与其实现分离，以便两者可以独立变化;
结构模式;
桥接模式是软件工程中使用的设计模式，旨在将抽象与其实现分离，以便两者可以独立变化。该桥使用封装，聚合，并且可以使用继承将职责分成不同的类;
当一个类经常变化时，面向对象编程的特性变得非常有用，因为可以用最少的关于程序的先验知识来容易地改变程序代码。当类和它的作用经常变化时，桥模式很有用。类本身可以被认为是实现以及类可以作为抽象来做什么。桥模式也可以被认为是两层抽象;
桥接模式经常与适配器模式混淆。实际上，桥接模式通常使用类适配器模式实现;
变体：通过将实现的存在推迟到使用抽象的程度，可以将实现更加分离。

桥模式理解

3 个答案: