你能否告诉我何时选择策略而不是多态，反之亦然。
非常感谢！
答案 0 :(得分：4)
一个重要的标准是多态性是否会产生策略会避免的耦合。例如，如果为使用低级I / O函数的类树实现“save（）”方法，那么如果使用多态，则类树将耦合到I / O系统，而它不是'之前。但是，如果使用策略模式，则策略对象将充当“缓冲区”，并使类树保持依赖于I / O.
答案 1 :(得分：1)
使用null启动应用程序。
下一步是具有多态性的原始代码。
对于基本情况，它可以保持这种方式 - 这不是问题。
如果您希望您的应用程序更灵活，为变更做好准备并且您计划继续开发它 - 是时候寻找一些设计模式了，策略是您应该思考的那个，当多态性给出一些时的烦恼。
<小时/> 战略意图：
定义一系列算法，封装每个算法，并使它们可互换。 策略允许算法独立于使用它的客户端。
<小时/> 使用策略的动机：
存在许多用于将文本流分解为行的算法。硬连接所有 这些算法进入需要它们的类中是不可取的 原因：
·需要换行的客户如果包含，则会变得更加复杂 换行代码。这使客户变得更大，更难维护， 特别是如果它们支持多种换行算法。
·不同的算法适用于不同的时间。我们不想要 如果我们不全部使用它们，则支持多种换行算法。
·在断线时添加新算法并改变现有算法很困难 是客户不可分割的一部分。 我们可以通过定义封装不同的类来避免这些问题 换行算法。调用以这种方式封装的算法 一个策略。
<小时/> 的后果：
相关算法的家族。策略类的层次结构定义了一个 用于上下文重用的算法或行为的系列。继承可以帮助 分解算法的常用功能。
子类化的替代方法.Inheritance提供了另一种支持方式 各种算法或行为。您可以继承Context类 直接给它不同的行为。但这种行为很难实现 进入Context.It将算法实现与Context的混合，制作 上下文更难理解，维护和扩展。你不能改变 算法动态。你结束了很多相关的课程 差异是他们使用的算法或行为。封装 单独的策略类中的算法允许您改变算法 独立于其背景，使其更容易切换，理解和 延伸。
策略消除条件陈述。策略模式提供 用于选择所需行为的条件语句的替代方案。 当不同的行为被归为一类时，很难避免使用 用于选择正确行为的条件语句。封装 单独的策略类中的行为消除了这些条件 语句。