桥与适配器设计模式

Question

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

以下是实施：

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

我一直认为它是适配器模式的实现，但实际上我不知道为什么不是 Bridge ！

我已经阅读了SO，GoF和维基百科中的所有帖子，但它确实毫无意义！

根据我的理解，两种模式指向现有类型，将抽象与其实现分离我错过了一点吗？

这是来自GoF：

  

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

我不完全理解上述陈述，

1. 这是否意味着如果我改变适应者或改变实施 在设计时的原始界面然后是 Bridge Pattern ？
2. 这些差异听起来微不足道，是否存在其他差异 实施/ abstcation？
3. 如何知道在之后使用的实施方式 发展？
4. 任何人都可以给我一个桥梁模式的好例子以及它如何 在软件生命周期中被更改？

更新

再次来自GoF：

  

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

这是否意味着更改现有界面以便它可以与其他界面一起使用是适配器的实现？

UPDATE2：

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

这是真正的Bridge Patter结构：

我错过了Bridge模式允许您组合不同的抽象和实现以及扩展它们的事实

Answer 1

我认为你这里没有纯粹的GoF模式。这是Decorator和Adapter之间的东西。您正在更改服务客户端的界面（根据您的需要进行调整）。但是你也在为客户增加新的职责（记录和错误处理） - 这就是装饰部分。如果你保留原始服务界面，它将是纯粹的装饰。

更新：继承的任何使用并不意味着我们正在使用一些GoF模式。你目前的架构遗漏了几件事：Bridge：

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

Answer 2

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

使用适配器模式，您不希望将两个具有不同意图的类层次结合起来，而是使一个类适用于您自己的接口。我想如果您在上面的示例中仅支持单个窗口系统，并且不在其间放置一个抽象类来维护可扩展性，那么这将是适配器而不是桥接器。

Answer 3

这在前面已经讨论过 - Difference between Bridge pattern and Adapter pattern - 你想从GoF得到的真实报价是“适配器让它们在设计之后起作用; Bridge使它们在它们出现之前就可以工作了。[GoF，p219]

你的上一个问题得到了肯定 - 一个适配器用于使系统中两个令人不愉快的元素很好地结合在一起，而不会改变它们的基本功能，除了可能将它们的功能联合分组 -

桥接模式通常用于处理初始设计中的问题，其中呈现给消费者的心理模型可能与实现消费者模型的实现的模型大不相同。考虑一个在各种各样的处理器中看起来相同的高性能数学库 - 你只想增加矩阵，但在幕后有各种各样的混乱涉及混合，并行数据流，避免管道停滞的奇怪行为，以及所有完成高性能超级计算机核心的3 +实现不同 - 那就是英特尔:-(