简体繁体 English

退化桥接模式用例

[英]Degenerate Bridge Pattern Use Cases

原文 2022-11-12 23:17:38 7 1 design-patterns/ abstraction/ bridge

I'm looking for elaboration on the Degenerate Bridge pattern.我正在寻找关于退化桥模式的详细说明。

GoF's Design Patterns book mentions a "degenerate case of the Bridge pattern" that has a "one-to-one relationship between Abstraction and Implementor", but what is the motivation for using such a pattern? GoF 的《设计模式》一书提到了一种“桥接模式的退化案例”，它具有“抽象与实现者之间的一对一关系”，但使用这种模式的动机是什么？

What is it exactly?究竟是什么？ Is there a still need for the Implementor interface?是否还需要 Implementor 接口？
What are examples or use cases of the pattern?该模式的示例或用例是什么？
Could the degenerate pattern turn into the non-degenerate Bridge pattern as the architecture evolves and more classes are added to the Implementor class hierarchy?随着体系结构的发展和更多类被添加到 Implementor class 层次结构中，退化模式能否转变为非退化桥接模式？ The assumption here is the Implementor remains even if there is one ConcreteImplementor.这里的假设是即使只有一个 ConcreteImplementor，Implementor 仍然存在。

1 个解决方案

This is all explained in the Implementation issues #1.这一切都在实施问题 #1 中进行了解释。

Only one Implementor .只有一个 Implementor 。 In situations where there's only one implementation, creating an abstract Implementor class isn't necessary.在只有一个实现的情况下，没有必要创建抽象的Implementor class。 This is a degenerate case of the Bridge pattern;这是 Bridge 模式的一个退化案例； there's a one-to-one relationship between Abstraction and Implementor . Abstraction和Implementor之间存在一对一的关系。 Nevertheless, this separation is still useful when a change in the implementation of a class must not affect its existing clients— that is, they shouldn't have to be recompiled, just relinked.然而，当 class 的实现中的更改不能影响其现有客户端时，这种分离仍然有用——也就是说，它们不必重新编译，只需重新链接即可。

Carolan [Car89] uses the term "Cheshire Cat" to describe this separation. Carolan [Car89] 使用术语“柴郡猫”来描述这种分离。 In C++, the class interface of the Implementor class can be defined in a private header file that isn't provided to clients.在 C++ 中， Implementor者 class 的 class 接口可以定义在不提供给客户端的私有 header 文件中。 This lets you hide an implementation of a class completely from its clients.这使您可以对其客户端完全隐藏 class 的实现。

So...所以...

what is the motivation for using such a pattern?使用这种模式的动机是什么？

"...this separation is still useful when a change in the implementation of a class must not affect its existing clients..." The example given is highly specific to compiled (as opposed to interpreted) languages, like C++. Still it's the same common theme that runs throughout the GoF book: composition is more flexible than inheritance. “......当 class 的实现中的更改不能影响其现有客户时，这种分离仍然有用......”给出的示例高度特定于编译（而不是解释）语言，如 C++。仍然是GoF 书中贯穿的相同主题：组合比 inheritance 更灵活。

Is there a still need for the Implementor interface?是否还需要Implementor接口？

"...creating an abstract Implementor class isn't necessary." “......创建一个抽象的Implementor class 是没有必要的。”

What are examples or use cases of the pattern?该模式的示例或用例是什么？

Carolan [Car89] refers to: J. Carolan. Carolan [Car89] 指：J. Carolan。 Constructing bullet-proof classes.构建防弹课程。 In Proceedings C++ at Work '89.在 89 年工作会议记录 C++ 中。 SIGS Publications, 1989. SIGS 出版物，1989 年。

I'm not sure if that exact paper is available online;我不确定网上是否可以找到那篇确切的论文； but Google shows a few promising results related to the title, including Interpreting "Supporting the 'Cheshire Cat' Idiom" .但谷歌显示了一些与标题相关的有希望的结果，包括Interpreting "Supporting the 'Cheshire Cat' Idiom" 。

Could the degenerate pattern turn into the non-degenerate Bridge pattern...退化模式能否变成非退化桥模式...

Anything could turn into anything, if you change the code, right?如果您更改代码，任何东西都可以变成任何东西，对吗？ An abstract Implementor class certainly makes the change easier, though.不过，抽象的Implementor class 肯定会使更改更容易。