策略模式和依赖注入有什么区别？

Question

策略模式和依赖注入都允许我们在运行时设置/注入对象。 策略模式和依赖注入有什么区别？

Answer 1

DI 和策略的工作方式相同，但策略用于更细粒度和短期的依赖关系。

当对象配置了“固定”策略时，例如构造对象时，策略和 DI 之间的区别就模糊了。 但在 DI 场景中，对象的依赖关系在其生命周期内发生变化的情况更为罕见，而这对于策略来说并不罕见。

此外，您可以将策略作为参数传递给方法，而方法参数注入的相关概念并不广泛，并且主要仅在自动化测试的上下文中使用。

策略侧重于意图，并鼓励您使用遵守相同行为契约的不同实现来创建接口。 DI 更多的是实现某些行为并提供它。

使用 DI，您可以出于其他原因分解您的程序，而不仅仅是为了能够交换部分实现。 DI 中使用的接口只有一种实现是很常见的。 只有一个具体实现（曾经）的“策略”并不是一个真正的问题，但可能更接近于 DI。

Answer 2

区别在于他们想要实现的目标。 策略模式用于您知道要交换实现的情况。 例如，您可能希望以不同的方式格式化数据 - 您可以使用策略模式来替换 XML 格式化程序或 CSV 格式化程序等。

依赖注入的不同之处在于用户不会尝试更改运行时行为。 按照上面的示例，我们可能会创建一个使用 XML 格式化程序的 XML 导出程序。 而不是像这样构造代码：

public class DataExporter() {
  XMLFormatter formatter = new XMLFormatter();
}

您可以在构造函数中“注入”格式化程序：

public class DataExporter {
  IFormatter formatter = null;

  public DataExporter(IDataFormatter dataFormatter) {
    this.formatter = dataFormatter;
  }
}

DataExporter exporter = new DataExporter(new XMLFormatter());

依赖注入有一些理由，但主要的理由是为了测试。 您可能会遇到这样的情况：您有某种持久性引擎（例如数据库）。 然而，当您重复运行测试时，使用真实的数据库可能会很痛苦。 因此，对于您的测试用例，您将注入一个虚拟数据库，这样就不会产生这种开销。

使用此示例，您可以看到差异：我们始终计划使用数据存储策略，并且它是我们传入的策略（真正的数据库实例）。 然而，在开发和测试中，我们想要使用不同的依赖项，因此我们注入不同的具体内容。

Answer 3

您可以使用 DI 作为策略模式，这样您就可以交换每个客户所需的算法，但 DI 可以超越这一点，因为它是一种解耦应用程序各部分的方法，这些部分不属于应用程序的一部分。战略模式。

在我看来，说 DI 只是重命名的策略模式是有风险的，因为这开始淡化策略模式的真正用途。

Answer 4

伙计，依赖注入是一种更通用的模式，它是关于对抽象而不是具体的依赖，它是每个模式的一部分，但策略模式是更具体问题的解决方案，

这是维基百科的定义：

DI：

依赖注入（DI）
面向对象的计算机编程
是一个有核心的设计模式
行为与行为分离的原则
依赖性解析。 换句话说：
一种高度解耦的技术
依赖的软件组件。

策略模式：

在计算机编程中，策略
模式（也称为策略
模式）是一个特定的软件
设计模式，算法可以
在运行时选择。

策略模式旨在
提供一种定义家族的方法
算法，将每个算法封装为一个
对象，并使它们可以互换。
策略模式让
算法的变化独立于
使用它们的客户。

Answer 5

策略是更高级别的事物，用于改变事物的计算方式。 通过依赖注入，您不仅可以更改计算方式，还可以更改其中的内容。

对我来说，使用单元测试时就变得很清楚了。 对于生产代码执行，您可以隐藏所有数据（即私有或受保护）； 而在单元测试中，大部分数据都是公开的，因此我可以使用断言来查看它。

---

策略示例：

public class Cosine {
  private CalcStrategy strat;

  // Constructor - strategy passed in as a type of DI
  public Cosine(CalcStrategy s) {
    strat = s;
  }
}

public abstract class CalcStrategy {
  public double goFigure(double angle);
}

public class RadianStrategy extends CalcStrategy {
  public double goFigure(double angle) {
    return (...);
  }
}
public class DegreeStrategy extends CalcStrategy {
  public double goFigure(double angle) {
    return (...);
  }
}

请注意，策略之间没有不同的公共数据。 也没有任何不同的方法。 两种策略共享所有相同的功能和签名。

---

现在进行依赖项注入：

public class Cosine {
  private Calc strat;

  // Constructor - Dependency Injection.
  public Cosine(Calc s) {
    strat = s;
  }
}

public class Calc {
  private int numPasses = 0;
  private double total = 0;
  private double intermediate = 0;

  public double goFigure(double angle) {
    return(...);
}

public class CalcTestDouble extends Calc {
  // NOTICE THE PUBLIC DATA.
  public int numPasses = 0;
  public double total = 0;
  public double intermediate = 0;
  public double goFigure(double angle) {
    return (...);
  }
}

使用：

public CosineTest {

  @Test
  public void testGoFigure() {
    // Setup
    CalcTestDouble calc = new CalcTestDouble();
    Cosine instance = new Cosine(calc);

    // Exercise
    double actualAnswer = instance.goFigure(0.0);

    // Verify
    double tolerance = ...;
    double expectedAnswer = ...;
    assertEquals("GoFigure didn't work!", expectedAnswer,
         actualAnswer, tolerance);

    int expectedNumPasses = ...;
    assertEquals("GoFigure had wrong number passes!",
        expectedNumPasses, calc.numPasses);

    double expectedIntermediate = ...;
    assertEquals("GoFigure had wrong intermediate values!",
        expectedIntermediate, calc.intermediate, tolerance);
  }
}

注意最后 2 个检查。 他们使用了测试替身中的公共数据，并将其注入到被测试的类中。 由于数据原因，我无法使用生产代码执行此操作
隐藏原则。 我不想在生产代码中插入特殊用途的测试代码。 公共数据必须属于不同的类别。

测试替身已被注入。 这与策略不同，因为它影响数据而不仅仅是功能。

Answer 6

依赖注入是策略模式的改进，我将简要解释这一点。 通常需要在运行时在多个替代模块之间进行选择。 这些模块都实现了一个公共接口，以便它们可以互换使用。 策略模式的目的是通过将决策过程封装到一个单独的对象（我将其称为策略对象）中来消除决定使用哪个模块（即哪个“具体策略”或依赖项）的负担。

依赖注入不仅决定使用哪种具体策略，而且还创建具体策略的实例并将其“注入”回调用模块，从而完善了策略模式。 即使只有一个依赖项，这也是有用的，因为如何管理（初始化等）具体策略实例的知识也可以隐藏在策略对象中。

Answer 7

实际上，依赖注入看起来也与桥接模式非常相似。 对我来说（根据定义），桥接模式是为了适应不同版本的实现，而策略模式是为了完全不同的逻辑。 但示例代码看起来像是使用 DI。 那么也许 DI 只是一种技术或实现？

Answer 8

策略是使用依赖注入技能的舞台。
实现依赖注入的真正方法如下： -

1. 事件
2. 统一/结构映射（或以编程方式）的配置文件等
3. 扩展方法
4. 抽象工厂模式
5. 控制模式反转（策略和抽象工厂都使用）

有一点是这样的：战略与众不同。 如您所知，在 Unity 中，当应用程序启动时，所有依赖项都已设置，我们无法进一步更改它。 但策略支持运行时依赖关系更改。 但我们必须管理/注入依赖，而不是策略的责任！

实际上策略并没有讲依赖注入。 如果需要，可以通过策略模式内的抽象工厂来完成。 策略只讨论创建具有接口的类系列并“玩”它。 在玩的时候，如果我们发现这些类处于不同的层，那么我们必须自己注入它，而不是策略的工作。

Answer 9

如果我们考虑 SOLID 原则 -
我们使用策略模式来实现开闭原则，使用依赖注入来实现依赖倒置原则