桥梁模式和战略模式有什么区别？

我试图阅读dofactory，维基百科和许多网站上的许多文章。 我不知道桥梁模式和战略模式之间的差异。

我知道他们都将抽象从其实现中分离出来，并且可以在运行时改变实现。

但是我仍然不知道在哪种情况下我应该使用策略，或者在哪种情况下我应该使用桥接。

语义。 从维基百科 ：

Strategy模式的UML类图与Bridge模式的图相同。 但是，这两种devise模式在意图上并不相同。 虽然战略模式是为了行为，桥梁模式是为了结构。

上下文和策略之间的耦合比桥接模式中抽象和实现之间的耦合更紧密。

据我所知，当你抽象可以从外部来源提供的行为时（例如.config可以指定加载一些插件程序集），你正在使用策略模式，并且当你使用桥接模式的时候相同的结构，使您的代码有点整齐。 实际的代码看起来非常相似 – 你只是稍微不同的原因应用模式。

Bridge模式是一种结构模式（您如何构build软件组件？）。 策略模式是一个dynamic模式（您如何在软件中运行行为？）。

语法是相似的，但目标是不同的：

  • 策略 ：你有更多的方法来做手术。 通过策略，您可以在运行时selectalgorithm，并且可以在编译时修改单个策略而不会产生很多副作用;
  • 桥 ：你可以拆分接口和类的层次结构，join一个抽象引用（参见说明 ）

战略：

  • 与策略相关的上下文：上下文类（可能是抽象的，但不是真正的接口！因为你想封装一个特定的行为而不是整个实现）将知道/包含策略接口引用和实现来调用策略行为它。

  • 意图是在运行时交换行为的能力 

    class Context { IStrategy strategyReference; void strategicBehaviour() { strategyReference.behave(); } }

桥

  • 抽象不绑定到实现：抽象接口（或抽象类与大多数行为抽象）不会知道/包含实现接口引用

  • 意图是将抽象与实现完全分离 

     interface IAbstraction { void behaviour1(); ..... } interface IImplementation { void behave1(); void behave2(); ..... } class ConcreteAbstraction1 implements IAbstraction { IImplementation implmentReference; ConcreteAbstraction1() { implmentReference = new ImplementationA() // Some implementation } void behaviour1() { implmentReference.behave1(); } ............. } class ConcreteAbstraction2 implements IAbstraction { IImplementation implmentReference; ConcreteAbstraction1() { implmentReference = new ImplementationB() // Some Other implementation } void behaviour1() { implmentReference.behave2(); } ............. }

桥 ：（一种结构模式）

桥接模式将抽象和实现分开，并允许两者独立地变化。

使用此模式时：

  1. 抽象和实现在编译时还没有确定
  2. 抽象和实现应该被独立地改变
  3. 抽象实现的变化不应该影响调用者的应用程序
  4. 客户应该与实施细节隔离。

策略:(行为模式）

策略模式使您能够在运行时在一系列algorithm中切换多个algorithm。

使用策略模式时：

  1. 需要多个版本的algorithm
  2. 类的行为必须在运行时dynamic改变
  3. 避免条件语句

相关文章：

你什么时候使用桥梁模式？ 与适配器模式有什么不同？

战略格局的现实世界范例

从wiki上的战略模式

Strategy模式的UML类图与Bridge模式的图相同。 但是，这两种devise模式在意图上并不相同。 虽然战略模式是为了行为，桥梁模式是为了结构。

上下文和策略之间的耦合比桥接模式中抽象和实现之间的耦合更紧密。

添加到willcodejavaforfood的答案，他们可以是相同的，在实施。 但是，您使用策略来交换策略（如sorting策略），而使用桥接来桥接两个对象的实现，即数据库包装器和networking适配器，以便客户端代码可以使用针对相同API的工作。 所以命名实际上是这样说的

我也是这样想的，但是最近我不得不使用桥接，并且意识到桥接器正在使用策略，并且将抽象添加到上下文中，以便稍后可以在不更改客户端的情况下进行更多的更改。 在没有抽象的情况下使用Strategy时，devise不够灵活，以后可能需要更改客户端。 但是，当使用整个桥时，devise变得更加灵活。 在这里，您可以了解Strategy to Bridge如何提供更大的灵活性。 我们还假设现在“签证”和“主人”不仅在卡上可用，而且在手机和芯片上也是如此; 如果我们使用桥梁，添加这个支持就容易多了。

战略与桥梁

只是增加了已经有关模式比较（意图差异，…）的说法：桥梁模式也是有意的结构化，以允许抽象层次方面的变化。 在像C＃这样的语言中，这可能意味着您有一个包含虚拟方法的抽象基础，作为允许对现有用户不造成问题的预期变化的一种方式。 除此之外，这两种模式大部分可能看起来完全相同。

当您希望在运行时插入algorithm或策略时使用策略模式。 作为模式的范畴也意味着它处理对象的行为。 另一方面，桥梁是结构模式，处理对象的结构层次。 它通过在它们之间引入一个精炼的抽象来将抽象从实现中解耦出来。 精炼的抽象可以与插入的运行时间策略混淆（在策略模式中）。 桥梁模式通过提供避免创buildn个类的机制来处理结构方面。

  1. 战略模式用于行为决策，而桥梁模式用于结构决策。

  2. Brigde Pattern将抽象元素从实现细节中分离出来，而Strategy Pattern则是让algorithm更易于互换。

UML中的战略模式

UML中的Brigde模式

Swift战略模式： 

 protocol PrintStrategy { func print(_ string: String) -> String } class Printer { let strategy: PrintStrategy init(strategy: PrintStrategy) { self.strategy = strategy } func print(_ string: String) -> String { return self.strategy.print(string) } } class UpperCaseStrategy: PrintStrategy { internal func print(_ string: String) -> String { return string.uppercased() } } class LowerCaseStrategy: PrintStrategy { internal func print(_ string: String) -> String { return string.lowercased() } } var lower = Printer(strategy: LowerCaseStrategy()) lower.print("I love Software Patterns") var upper = Printer(strategy: UpperCaseStrategy()) upper.print("I love Software Patterns")

快速的Brigde模式： 

 protocol Appliance { func run() } protocol Switch { let appliance: Appliance {get set} func turnOn() } class RemoteControl: Switch { var appliance: Appliance init(appliance: Appliance) { self.appliance = appliance } internal func turnOn() { appliance.run() } } class TV: Appliance { internal func run() { print("TV is ON") } } class Stereo: Appliance { internal func run() { print("Stereo is ON") } } var tvRemote = RemoteControl.init(appliance: TV()) tvRemote.turnOn() var stereoRemote = RemoteControl.init(appliance: Stereo()) stereoRemote.turnOn()

对于战略模式，只有实施情况不一。

假设A类正在使用具有多个可用实现的B类。 所以在这种情况下，B将在运行时提供实际的实现。 这是战略模式

现在，如果A本身是抽象的。 A和B都可能有所不同。 你会使用桥梁模式。

我认为他们在使用的环境中有一些细微的差别。

我使用Bridge模式来分离它们都属于一个更大的正交概念 – 让它们独立变化。 它通常涉及多个抽象。

海事组织，战略模式更简单或更平坦。 它确实服务于OCP，但不一定是Bridge模式等另一个更大的概念的一部分。

Interesting Posts