什么时候在重构switch语句时选择策略over多态性

Question

您可以给我特定的原因何时选择stratigy而不是polymorphsim，反之亦然。

非常感谢！

Answer 1

一个重要的标准是多态性是否会产生策略会避免的耦合。例如，如果为使用低级I/O函数的类树实施“save（）”方法，那么如果使用多态性，则类的树将耦合到I/O系统，而不是“ t之前。但是，如果您使用策略模式，那么策略对象将充当“缓冲区”并使类树不依赖于I/O。

Answer 2

你用null开始你的应用程序。

下一步是多态的原始代码。

基本情况下，它可以保持这种方式 - 这不是问题。

如果你希望你的应用程序更加灵活，为变化做好准备，并且你打算继续开发它 - 现在是时候去寻找一些设计模式了，当多态现象给出时，策略就是你应该考虑的巫师之一一些麻烦。

---

意向策略：

定义一系列的算法，封装每一个，使得它们可以互换。策略可以让算法独立于使用它的客户端。

---

动机使用策略：

许多算法打破文本流成存在lines.Hard布线所有 这种算法到需要它们的类是不可取的几个 原因：

·如果包含 换行代码，需要换行的客户会变得更加复杂。这使得客户端变得越来越难以维护，特别是如果它们支持多种换行算法的话。

·不同的算法在不同的时间适用。如果我们不全部使用它们，我们不希望 支持多种换行算法。

·当线路中断 是客户端的一个组成部分时，很难添加新的算法和改变现有的算法。 我们可以通过定义封装不同的 换行算法的类来避免这些问题。以这种方式封装的算法被称为 策略。

---

后果：策略类的相关algorithms.Hierarchies的

1. 家庭定义 家庭的算法或行为的上下文重用。继承可以帮助将算法的常用功能分解出来。

2. Subclassing.Inheritance的替代方法提供了另一种支持多种算法或行为的方法。您可以直接对Context类 进行子类化，以赋予它不同的行为。但是这会将行为 硬连接到Context中。它将算法实现与Context相混合，使上下文更难以理解，维护和扩展。并且您不能动态改变 算法。你会发现许多相关的类，它们只有它们所使用的算法或行为不同。将 算法封装在单独的策略类中，可让您独立于其上下文来更改算法 ，从而更轻松地切换，理解和扩展 。

3. 策略消除条件语句。策略模式提供 条件语句的替代选择所需的行为。 当不同的行为被集中到一个类中时，很难避免使用条件语句来选择正确的行为。在单独的策略类中封装 行为将消除这些条件 语句。