关于c#:Bridge与适配器设计模式

Bridge vs. Adapter Design Pattern

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

这是实施:

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

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

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

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

这是来自GoF:

The key difference between these patterns lies in their intents.
Adapter focuses on resolving incompatibilities between two existing
interfaces. It doesn't focus on how those interfaces are implemented,
nor does it consider how they might evolve independently. It's a way
of making two independently designed classes work together without
reimplementing one or the other. Bridge, on the other hand, bridges an
abstraction and its (potentially numerous) implementations. It
provides a stable interface to clients even as it lets you vary the
classes that implement it. It also accommodates new implementations as
the system evolves.

我不完全理解上述说法,

  • 这是否意味着如果我改变适应者或改变实施
    在设计时的原始界面然后它是桥模式?
  • 这些差异听起来微不足道,是否存在其他差异
    执行/ abstcation?
  • 怎么会有人告诉我之后使用什么实现
    发展?
  • 任何人都可以给我一个桥梁模式的好例子,以及它如何
    在软件生命周期中改变?
  • 更新:

    再次来自GoF:

    Remember that an adapter makes two existing interfaces work together
    as opposed to defining an entirely new one.

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

    UPDATE2:

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

    这是真正的Bridge Patter结构:

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


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

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

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


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

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


    这在前面已经讨论过 - 桥接模式和适配器模式之间的区别 - 你想从GoF获得的真实报价是"适配器使它们在设计之后工作; Bridge使它们在它们工作之前工作。[GoF,p219]

    你的最后一个问题是肯定的 - 一个适配器用于使一个系统的两个令人不愉快的元素很好地在一起运行,而不会改变它们的基本功能,除了可能将其功能的联合分组 -

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