是否存在Abstract类优于Interface的情况

Question

我有一个场景，其中有几个子类有类似的实现和一些额外的方法，实现与每个子类不同。我假设抽象类对于这种情况是一个不错的选择。但是如果抽象类实现包含所有方法声明的接口会更好。或者我应该坚持使用抽象类。

简而言之，我想知道我应该更喜欢层次结构顶部的抽象类而不是接口的场景。

Answer 1

如果您的子类与抽象类具有is-a关系，请使用抽象类。

您可以同时拥有抽象类和接口 - 指定实现的抽象类，以及指定API的接口。

集合框架就是一个例子 - 它有ArrayList extends AbstractList implements List

Answer 2

抽象类不必是完全抽象的。您可以定义所有子类将按原样使用的某些函数（和变量），并且只留下某些子类要实现的方法。接口具有无法定义任何功能的限制。

另一方面，接口允许类灵活地实现多个接口，而类只能扩展另一个类。从这个意义上讲，接口可能总是优于纯粹的抽象类。但是抽象类仍然有很多用途，它们包含一些重用的功能。

Answer 3

抽象类可以提供接口不能的默认行为。当一部分行为在几个子类中很常见时，这就变得很敏感。

很好地利用了模板方法模式：http://en.wikipedia.org/wiki/Template_method_pattern，它减少了顺序耦合。

Answer 4

请记住，使用Abstract类，您可以定义子类具有的数据。使用interface，您只能定义实现者必须实现的方法。那么在您的情况下，您是否需要通用数据和常用方法或只需要常用方法？

Answer 5

抽象类允许您随身携带一些代码/数据，然后可以在继承的类中使用它们。它们很棒，但是非常谨慎地使用继承。如果新类绝对可以与抽象互换，则只从类继承。

接口不包含代码。

我更喜欢尽可能编码接口。我也想保持这些接口尽可能小。这使我可以灵活地在以后更换底层的修正。

如果你编写一个抽象类，那么以后更换实现就更难了。

您可以将一个接口（或几个小接口）应用于抽象类。听起来这可能是你最好的方法。

Answer 6

始终支持界面。你应该努力避免抽象类。有了这个说，抽象类有一个地方，尤其是类似于Java集合的库存代码。在这些地方，您正在构建专为扩展目的而设计的类，并且在巩固行为方面具有很大价值，尤其是从质量角度来看。