桥接器与适配器设计模式

Question

一位同事向我询问了我在 ASP.net 客户端应用程序中实现 WCF Windows 服务的设计模式，我真的不知道它是 Bridge 还是 Adapter ！

这里是实现：

• 我已获得服务合同
• 定义了一个类似于我的 WCF 数据合同的新接口
• 我创建了一个 WCF 客户端并将其包装在新界面中
• 将新的接口操作映射到原来的 WCF 客户端（我在这里做了一些日志记录/错误处理）

我一直认为它是Adapter模式的实现，但我真的不知道为什么不是Bridge！

我已经阅读了 SO、GoF 和 wikipedia 中的所有帖子，但这真的毫无意义！

据我了解，两种模式都指向现有类型，都将抽象与其实现解耦我是否遗漏了一点？

这是来自 GoF：

这些模式之间的主要区别在于它们的意图。 适配器专注于解决两个现有的不兼容问题 接口。它并不关注这些接口是如何实现的， 它也没有考虑它们如何独立发展。这是一种方式 让两个独立设计的类在没有的情况下一起工作 重新实现一个或另一个。另一方面，桥接 抽象及其（可能很多）实现。它 为客户提供稳定的界面，即使它允许您改变 实现它的类。它还适应新的实现，如 系统在进化。

上面的说法我不太明白，

1. 这是否意味着如果我更改适配者或更改实现 设计时的原始界面，那么它是桥接模式？
2. 差异听起来微不足道，是否还有其他差异 实施/抽象化？
3. 谁能知道之后使用了什么实现 开发？
4. 谁能给我一个很好的桥接模式示例以及它如何 在软件生命周期内进行更改？

更新：

再次来自 GoF：

请记住，适配器使两个现有接口协同工作 而不是定义一个全新的。

这是否意味着更改现有接口以使其可以与另一个接口一起使用是 Adapter 的实现？

更新2：

刚刚发现这篇令人难以置信的文章：Illustrated GOF Design Patterns in C#

这是真正的 Bridge Pattern 结构：

我错过了桥模式允许您组合不同的抽象和实现并独立扩展它们的事实

Answer 1

我认为这里没有纯 GoF 模式。这是装饰器和适配器之间的东西。您正在更改服务客户端的界面（使其适应您的需要）。但是您也在向客户端添加新职责（日志记录和错误处理） - 这是一个装饰部分。如果你要保留原来的服务接口，那将是纯粹的装饰器。

更新：任何继承的使用并不意味着我们正在使用某种 GoF 模式。您当前的架构缺少桥接功能：

• 实施层次结构。您的服务接口应该定义一些低级操作。你应该有几个服务实现。
• 抽象应该定义高级接口。通常这些接口看起来不像实现接口（您的客户端接口类似于服务接口，它存在于同一抽象级别上）。
• 抽象实现应该使用服务接口来实现高级操作（即，它们不向服务添加一些职责，它们实现不同的东西，高级的东西）。

Answer 2

这点之前已在此处讨论过 - Difference between Bridge pattern and Adapter pattern - 您想要从 GoF 获得的真正引述是“适配器在设计完成后使它们工作；Bridge 使它们在它们之前工作。[GoF，p219]

您的最后一个问题是肯定的 - 适配器用于使系统中两个原本令人不快的元素很好地结合在一起，而不会改变它们的基本功能，而不会改变它们的功能联合 -

桥接模式通常用于处理初始设计中呈现给消费者的心智模型可能与实现消费者模型的模型大不相同的问题。考虑一个高性能数学库，它在各种处理器上看起来都一样——你只是想将矩阵相乘，但在幕后有各种各样的麻烦，包括混合、并行数据流、避免管道停顿的奇怪行为，等等。在 3+ 个高性能超大规模内核的实现上有所不同——这只是英特尔 :-(

Answer 3

我被解释为桥接模式旨在结合具有不同目的的两个类层次结构。例如，考虑您正在编写一个具有不同类型控件并支持不同窗口系统的窗口框架。您将拥有一个用于控件的类树，而另一个用于抽象出窗口系统之间的差异。现在，如果您想添加对另一个窗口系统的支持，只需将其添加到层次结构的那一侧，如果您想添加新控件，请将它们添加到它们的一侧。 “桥梁”存在于两个层次结构的顶级类之间，您的控件类可以访问由实现对各种窗口系统的支持的类层次结构的基类定义的抽象函数。

使用适配器模式，您不想组合具有不同意图的两个层次结构的类，而是调整一个类以使用您自己的接口。我想如果你在上面的例子中只支持一个单一的窗口系统并且没有在中间放置一个抽象类来保持可扩展性，那将是一个适配器而不是一个桥接器。