问题标签 [bridge]

有没有人在现实世界的应用程序中使用过桥接模式？如果是这样，你是如何使用它的？是我，还是只是适配器模式加上一点依赖注入？它真的值得拥有自己的模式吗？

我在看代理模式，对我来说，它看起来很像装饰器、适配器和桥接模式。我是不是误会了什么？有什么不同？为什么我要使用代理模式而不是其他模式？您过去是如何在现实世界的项目中使用它们的？

Say I have a hierarchy of classes, let's use the classic Shape examples:

abstract class Shape
Circle : Shape
Square : Shape

I have a second hierarchy of renderer classes that handle the rendering of shapes in different ways:

abstract class ShapeRenderer
HtmlShapeRenderer : ShapeRenderer
WindowsFormsShapeRenderer : ShapeRenderer

Allowing these to vary independently would traditionally involve using the Bridge pattern. Allowing the rendering actions to be extended without modifying the Shape classes would traditionally involve the Visitor pattern.

However, both of these focus exclusively on extending the implementation side and not the abstraction side. Say I wanted to add a new Shape, say Triangle - I want to be able to support rendering the Triangle as well. Since both the Visitor and the Bridge pattern rely on "flattening" the abstraction hierarchy into a set of methods, e.g.:

The only way to extend the Shape hierarchy is to modify the code of the base ShapeRenderer class, which is a breaking change.

Jon, to clarify: Using the Bridge or Visitor allows clients to provide alternative rendering implementations, but requires them to know about all potential Shapes. What I'd like to be able to do is allow clients to also be able to extend the Shape class and require them to provide a rendering implementation for their new class. This way, existing code can work with any type of Shape, without worrying about the particulars of rendering them.

Is there a common solution to this sort of problem usable in C#?

我尝试阅读有关dofactory、维基百科和许多网站的许多文章。我不知道桥接模式和策略模式之间的区别。

我知道它们都将抽象与其实现分离，并且可以在运行时更改实现。

但是我还是不知道在什么情况下应该使用策略，或者在什么情况下应该使用桥牌。

桥接模式和适配器模式有什么区别？

我花了一些时间在维基百科的这个桥模式示例上，但是，我仍然不明白这个桥模式试图解释什么。

子类 CircleShape 构造函数接受 4 个参数，在它的 draw() 方法中，前 3 个参数被传递给第四个参数，它可以是来自 DrawingAPI 的任何子类。那么这是否意味着使用桥接模式可以增加灵活性呢？这个例子还能告诉我们更多的事情吗？

谢谢！！！！

任何人都可以为我详细说明 Bridge 设计模式和 Decorator 模式。我发现它在某些方面很相似。不知道怎么区分？

我的理解是，在Bridge中，它将实现与接口分开，通常您只能应用一种实现。装饰器是一种包装器，你可以尽可能多地包装。

例如，

桥梁模式

装饰图案

我正在阅读一些关于设计模式的书籍，虽然有些书将抽象和实现之间的关系描述为组合，但有些书将其描述为聚合。现在我想知道：这是否取决于实现？关于语言？还是语境？

这个问题来自“Thinking in C++” Vol-1，Chapter 5's practice No.14：

使用“柴郡猫”技术创建一个 StackOfInt 类（一个包含整数的堆栈），该技术隐藏了用于将元素存储在名为 StackImp 的类中的低级数据结构。实现两种版本的 StackImp：一种使用固定长度的 int 数组，另一种使用向量。为堆栈预设最大大小，因此您不必担心在第一个版本中扩展数组。请注意，StackOfInt.h 类不必随 StackImp 更改。

StackOfInt.h这是我创建的头文件 ( )：

但是，对于实现，我对如何处理数组和向量之间的差异感到困惑。到目前为止，这是我想出的：

我想我走错了路，谁能给我一些关于如何解决这个问题的提示？

在我的项目中，我使用了一个不断变化的 3rd 方库。我有这个库的包装类（桥模式 + Pimpl 模式）。因此，除了包装器实现之外，我的任何来源都没有看到该库。这个库有一个 Options 结构，例如

我希望这个结构在 GUI 模块中可用，以构建一个允许设置这些选项的对话框。我需要为它创建一个包装结构吗？例如

或者我应该直接将该结构标头包含到我的源代码中吗？

包装器的缺点是：复制粘贴，用于在结构之间转换的附加代码。直接的缺点包括：打破 pimpl 成语。

这个问题可能还有其他解决方案吗？

另外我想强调的是，第 3 方库是不断变化的，所以我必须采用我的资源来支持库的每个新版本。