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