桥与适配器设计模式

Question

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

这是实施:

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

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

我已经阅读了SO,GoF和维基百科中的所有帖子,但它确实没有意义!

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

这是来自GoF:

这些模式之间的关键区别在于它们的意图.Adapter专注于解决两个现有接口之间的不兼容问题.它没有关注这些接口的实现方式,也没有考虑它们如何独立发展.这是一种让两个独立设计的类一起工作而不重新实现其中一个的方法.另一方面,Bridge桥接了一个抽象及其(可能很多)实现.它为客户提供了一个稳定的界面,因为它允许您改变实现它的类.随着系统的发展,它还适应新的实现.

我不完全理解上述说法,

1. 这是否意味着如果我在设计时更改了适配器或更改了原始界面的实现,那么它是Bridge Pattern？
2. 差异听起来微不足道,在实施/排除方面还有其他差异吗？
3. 怎么会有人说出 开发后使用了什么实现？
4. 谁能给我一个很好的桥接模式示例,以及如何在软件生命周期中对其进行更改？

更新:

再次来自GoF:

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

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

UPDATE2:

刚刚发现这篇令人难以置信的文章:C#中的插图GOF设计模式

这是真正的Bridge Patter结构:

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

之前已经在这里讨论过 - Bridge 模式和 Adapter 模式之间的区别- 您想要从 GoF 那里得到的真正引用是“Adapter 让事情在设计后工作；Bridge 让它们在设计之前工作。[GoF，p219]

你的最后一个问题得到了肯定 - 适配器用于使系统中两个原本不愉快的元素很好地协同工作，而不改变它们的基本功能，除了可能子集其功能的联合之外 -

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