在策略设计模式中使用抽象类而不是接口答案

【问题标题】：Using an abstract class instead of the interface in the Strategy design pattern在策略设计模式中使用抽象类而不是接口
【发布时间】：2014-09-25 17:58:30
【问题描述】：

我只是在学习 Java 和设计模式，我正在努力弄清楚何时使用接口和抽象类。我想知道在策略设计模式中，为什么对行为/算法子类使用接口而不是抽象超类更可取？

仅仅是因为不需要抽象类，因为每个行为/算法子类都有自己的实现，因此抽象超类只会提供不会使用的额外功能吗？

抽象类是否意味着将来有额外的可能性可以在需要时使用此额外功能，例如，如果需要，将方法添加到由行为/算法子类共享的抽象超类。有什么理由说明这是个坏主意吗？

还是有其他原因？

【问题讨论】：

设计模式是关于它们背后的一般思想，不一定是确切的实现。接口和抽象类方面是可以互换的。
接口也给你更多的灵活性，因为实现类可以实现多个接口或额外扩展一个类。
如果有疑问，请同时使用 :D 使抽象类实现接口并从抽象类扩展

标签： java oop inheritance design-patterns interface

【解决方案1】：

从实现的角度来看，您可以同时使用接口和抽象类。区别在于使用目的。

接口的主要目的是为其他类提供方法（即通信点）。 IE。解耦和依赖倒置。
抽象类的主要目的是帮助您在它们之上构建继承结构。

在策略模式中，如果你使用一个AbstractState来定义一个通用的代码库，你仍然可以在ContextIState接口/em> 和 AbstractState 将它们进一步解耦。

【讨论】：

【解决方案2】：

在 Java 8 之前，接口存在一个大问题：如果不破坏该接口的每个实现，就不可能添加额外的功能（即添加新方法）。抽象基类是避免这个问题的一种方法。

Java 8 引入了default methods，主要解决了这个问题。因此，对于现代 Java 系统，接口提供了更大的灵活性而没有缺点。

【讨论】：

其实我也想问这个，谢谢你解决这个问题。那么这是否意味着抽象类现在比 Java 8 之前的用处要小得多？
@JonnyShanahan 我认为这完全取决于情况和开发人员。在过去 20 年的 OO 编程中，我发现通过使用继承和增加使用接口 + 组合，我已经大大减少了。对我来说，这导致更少的耦合，更可维护的设计。也就是说，我主要使用 Java 进行开发，并且我确实希望该语言具有“混合”功能（它将消除一些广泛使用的模式中的大量样板，例如属性更改支持）。

【解决方案3】：

您应该为所有策略使用一个通用接口，并创建一个实现它的抽象类。因此，尽管您的所有策略目前共享一个抽象类，但您的系统是可扩展的，因为您可以在未来创建与该抽象类无关的策略。

现在只使用超类的某些方法是您应该做出的决定。它可能值得或不值得。

注意:: 如果你使用类似于模板方法模式的东西，你应该检查如何使用钩子。

【讨论】：

好的，所以最好尽可能限制系统的可扩展性？（我刚刚添加了第三段，它实际上提出了这个问题）。我想这本身就转向了一个不同的话题
不，不限制可扩展性。为什么要使用抽象类而不是接口？因为你的子类有一些你不应该重复的通用代码。但是，如果您只使用抽象类，则不能使用不使用此功能的策略（除非您创建空方法，否则情况完全不同）。

【解决方案4】：

在使用接口或抽象模式之间没有硬性规定。使用最适合您的情况。

如果您有多个非常相似的策略实现，当然您可以使用抽象类甚至子类化策略之一。

【讨论】：