谁应该实例化和分配运行时策略实现？答案

【问题标题】：who should instantiate and assign runtime strategy implementations?谁应该实例化和分配运行时策略实现？
【发布时间】：2009-12-23 03:59:27
【问题描述】：

在实现策略模式时，如何确定哪个类负责为：

选择具体的具体策略实现传递给Context类（假设选择是基于一些复杂的业务逻辑而不是静态标志）
实例化上述具体实现并将其实际注入到 Context 类中

感觉应该有一些客观的指导来涵盖这一点。我已经阅读了各种 OOP 模式（即 GRASP 和 SOLID），但我仍然对这个特定问题不太清楚。

【问题讨论】：

标签： design-patterns dependency-injection strategy-pattern

【解决方案1】：

这与我在使用 DI 容器时遇到的问题非常接近。看看here，Mark Seemann 提供了一个很好的答案。

【讨论】：

【解决方案2】：

如果您正在尝试解决特定情况，您正在寻找abstract factory pattern。工厂根据运行时信息确定如何实例化一系列类型。

如果您想知道如何抽象地解决这种情况，您正在寻找一个Inversion of Control container，它管理依赖项的组织和实现。策略的注册将包含条件逻辑。

【讨论】：

我在工作中使用 Spring.NET 进行 IOC，但我看不到将具体实现与条件逻辑相关联的简单方法，至少在使用纯 XML 配置解决方案时不会。
不知道如何将条件逻辑放到Spring.NET中。我使用 Autofac，它使用 lambda 表达式，因此在注册时允许任何逻辑。在您的情况下，我认为您应该声明一个工厂并将其注册到您的 IoC 容器中。这将允许您集中条件逻辑，同时将其分发给任何需要它的人。

【解决方案3】：

这种决定是特定于上下文的，就像设计模式的其他一切一样。引用 GoF 的书（斜体是我的）：

什么是设计模式？

Christopher Alexander 说：“每个模式都描述了一个在我们的环境中反复出现的问题，然后描述了该问题解决方案的核心，以这样一种方式，您可以使用该解决方案一百万次， 从来没有以同样的方式重复过两次” [AIS+77，第 x 页]。尽管 Alexander 谈论的是建筑物和城镇中的模式，但他所说的面向对象的设计模式是正确的。我们的解决方案是用对象和界面而不是墙和门来表达的，但两种模式的核心是在上下文中解决问题。

...

解决方案描述了构成设计的元素、它们的关系、职责和协作。解决方案没有描述特定的具体设计或实现，因为模式就像一个模板，可以应用于许多不同的情况。相反，该模式提供了对设计问题的抽象描述，以及元素（在我们的例子中为类和对象）的一般安排如何解决它。

【讨论】：