桥梁模式和策略模式

Question

SO比较桥模式和策略模式有很多问题。解释包括

  

桥梁是结构性的，战略是行为性的

和

  

UML和代码看起来相似，但意图不同

还有其他一些不太常见的

我在这里或其他地方遇到的所有解释都不令人满意。我清楚地知道，由于我的意图和需要解决的问题，我在使用“策略”模式和“桥接”模式时，但是从远处看，区别变得模糊了。因此，这个问题使我不时忙于工作。

如果我在对组件的结构进行建模时使用Bridge模式，那么它自然不会在运行时成为Strategy模式吗？

编辑：根据要求，我正在添加问题

This answer说，UML图和代码相似，但是用法可能有所不同。 This answer说，它们的语法相似，但目标不同。 This answer说，其中一个是结构性的，另一个是行为性的。 This answer非常接近，但最后，没有唯一的原因导致桥接器在运行时也是策略。 This answer也是值得一读的，但仍然引出了同样的问题；桥接模式在运行时变为策略模式？我们的意图是唯一的区别吗？

编辑2 ：我想提出不同的要求。仅查看源代码，例如this Strategy Pattern example和this Bridge Pattern example，您如何分辨策略模式中的桥接模式？看来我们可以将它们交换为示例代码，并且教程仍然有意义。

Answer 1

桥梁与战略之间的表面比较似乎集中在每个模式的主要组成部分之间的构成关系上。这种关系是比较的虚假基础，因为大多数GoF设计模式都采用了组合（因此，其著名的原理是：“从类继承中实现对象的组合”。）

相反，请注意Bridge中的组合关系将一个抽象链接到另一个抽象，而Strategy中的组合关系将实现链接到抽象。当客户端依赖于一个（抽象）API时，Bridge很有用，该API是根据单独的不同API来实现的。当客户端是一个具体的实现，可以通过使用多种算法来修改其行为时，策略就很有用。

这些模式之间的抽象范围也有所不同。 Bridge使用一个API完全实现另一个API。客户端API将所有调用委托给实现者（不可见地委托给客户端）。策略使用API​​作为客户端实现的一部分。策略不能实现整个客户端API。

摘要

桥

• 抽象有一个抽象
  1. 第一个抽象是客户端API。
  2. 第二个抽象是实现者API。
• 实施者对客户端隐藏，与客户端API不匹配。
• 客户端API将所有调用转发给实现者。

策略

• 实施具有抽象
  1. 实现是客户端，或由客户端构造的对象。
  2. 抽象是策略API。
• 客户选择了一种具体的策略，因此它的API是已知的并且符合客户的要求。
• 客户实施将一项特定操作转发给该策略。客户端API的其余部分与该策略无关。

---

最后，请注意，这两种模式在现代OOP中都不是特别常见的。 Bridge是一个利基案例，需要先验计划，而Strategy现在通过lambda或闭包本身得到支持。