您能给我具体的原因，何时选择策略模式而不是多态性，反之亦然。
非常感谢！
2个回答
4
一个重要的标准是多态是否会创建耦合，而策略能够避免这种情况。例如，如果为一组类实现“save()”方法需要使用低级别I/O函数，则如果您使用多态，这组类将与I/O系统耦合在一起，但之前并没有耦合。然而，如果您使用策略模式，则策略对象将充当“缓冲区”，使该组类不依赖I/O系统。
- Ernest Friedman-Hill
1
你的应用程序从 null 开始。
下一步是使用多态的原始代码。
对于基本情况，它可以保持这种方式 - 这不是问题。
如果你想让你的应用程序更加灵活，为未来的变化做好准备，并且计划继续开发它 - 现在是时候寻找一些设计模式了，策略模式是其中之一，当多态性带来一些麻烦时，你应该考虑使用它。
策略模式的意图：
定义一组算法，将每个算法封装起来，并使它们可以互换。 策略模式使得算法的变化独立于使用它的客户端。
使用策略模式的动机：
有许多算法可用于将文本流分成行。将所有这些算法硬编码到需要它们的类中并不理想，原因如下：
· 如果包含断行代码，需要断行的客户端会变得更加复杂。这使得客户端变得更大、更难以维护，特别是如果它们支持多个断行算法。
· 不同的算法在不同的时间段内是适用的。如果我们不使用它们所有，我们不想支持多个断行算法。
· 当断行是客户端的一个重要部分时，添加新算法和变化现有算法会变得困难。 我们可以通过定义封装不同断行算法的类来避免这些问题。以这种方式封装的算法称为策略。
结果：
相关算法族。策略类的层次结构定义了一组算法或行为，供上下文重用。继承可以帮助因式分解算法的共同功能。
子类化的替代方案。继承提供了另一种支持多种算法或行为的方式。您可以直接对上下文类进行子类化，以赋予它不同的行为。但这会将行为硬编码到上下文中。它将算法实现与上下文混合在一起，使得上下文更难理解、维护和扩展。而且您无法动态地改变算法。最终，您会得到许多相关的类，它们唯一的区别就是所使用的算法或行为。将算法封装在单独的策略类中，可以让您独立地改变算法，而不影响其上下文，从而使其更容易切换、理解和扩展。
策略消除条件语句。策略模式为选择所需行为提供了一种替代条件语句的方法。当不同的行为被归为一类时，很难避免使用条件语句来选择正确的行为。将行为封装在单独的策略类中可以消除这些条件语句。
- dantuch
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接