是否存在抽象类优于接口的场景
我遇到的情况是，有几个子类具有类似的实现，并且有一些额外的方法，每个子类的实现都不同。我认为抽象类对于这种情况是一个不错的选择。但是，如果该抽象类实现一个包含所有方法声明的接口会更好吗？或者我应该坚持使用抽象类。
简而言之，我想知道在什么情况下我应该更喜欢位于层次结构顶部的抽象类而不是接口。
I am having a scenario where there are several subclasses which have got similar implementations and some extra methods for which the implementations differ with each subclass. I assume that an abstract class would be a good choice for this scenario. But would it be better if that abstract class implements an interface which contains all method declarations.Or should I just stick with the abstract class instead.
In short, I would like to know the scenarios where I should prefer Abstract classes at the top of the hierarchy rather than an Interface.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您的子类与抽象类存在 is-a 关系，请使用抽象类。
您可以同时拥有抽象类和接口 - 抽象类指定实现，接口指定 API。
集合框架就是一个例子 - 它有 ArrayList extends AbstractList Implements List
Use the abstract class if your subclasses have is-a relationship with the abstract class.
You can have both an abstract class and an interface - the abstract class specifying implementations, and the interface specifying the API.
The collections frameworks is an example of that - it has
ArrayList extends AbstractList implements List抽象类不必是完全抽象的。您可以定义所有子类将按原样使用的某些函数（和变量），并仅保留某些方法由子类实现。接口有一个限制，即不能定义任何函数。
另一方面，接口允许一个类灵活地实现多个接口，而一个类只能扩展另一个类。从这个意义上说，接口可能总是比纯粹的抽象类更可取。但是抽象类仍然有很多用途，其中包含一些重用的功能。
An abstract class doesn't have to be completely abstract. You can define certain functions (and variables) that all subclasses will use as-is, and leave only certain methods to be implemented by the subclasses. An interface has the limitation that no functions can be defined.
On the flip side, interfaces allow the flexibility for a class to implement multiple interfaces, whereas a class can only extend one other class. In this sense, an interface will probably always be preferable to a purely abstract class. But there are still plenty of uses for abstract classes which do contain some reused functionality.
抽象类可以提供接口无法提供的默认行为。当部分行为在多个子类中通用时，这是有意义的。
一个很好的用途是模板方法模式： http://en.wikipedia.org/wiki/Template_method_pattern 减少顺序耦合。
Abstract class can provide default behaviour where Interfaces cannot. This make sens when a part of the behaviour will be common accross several subclasses.
A very good use of that is the template method pattern : http://en.wikipedia.org/wiki/Template_method_pattern which reduce sequential coupling.
请记住，使用抽象类，您可以定义子类具有的数据。使用接口，您只能定义实现者必须实现的方法。那么在您的情况下，您需要通用数据和通用方法还是只需要通用方法？
Remember that with Abstract class, you can define data that the subclasses have. With interface, you can only define methods that implementers must implement. So in your situation, do you need common data and common methods or just common methods?
抽象类允许您携带一些代码/数据，然后可以在继承的类中使用它们。它们非常适合这一点，但很少使用继承。仅当新类与抽象类绝对可互换时才从类继承。
接口不包含任何代码。
我更喜欢尽可能对接口进行编码。我还喜欢使这些接口尽可能小。这使我可以在以后灵活地更换底层实现。
如果您对抽象类进行编码，则以后更换实现会更加困难。
您可以将一个接口（或几个小接口）应用于抽象类。听起来这可能是你最好的方法。
Abstract classes let you carry around some code/data that you can then use in the inherited classes. They are great for that, but use inheritance very sparingly. Only inherit from a class if the new class is absolutely interchangeable with the abstract.
Interfaces contain no code.
I prefer to code to interfaces whenever possible. I also like to keep those interfaces as small as possible. This leaves me the flexibility to swap out the underlying impementation at a later time.
If you code to an abstract class, it is harder to swap out the implementation at a later time.
You can apply an interface (or several small interfaces) to the abstract class. Sounds like this may be your best approach.
始终偏爱界面。你应该尽力避免抽象类。话虽如此，抽象类尤其在类似于 java 集合的库代码中占有一席之地。在这些地方，您正在构建专门为扩展目的而设计的类，并且在巩固行为方面有很多价值，尤其是从质量角度来看。
Always favor interface. You should try very hard to avoid abstract classes. With that being said abstract classes have a place especially in libraryish code akin to java collections. In these places you are building classes that are expressly designed for the purpose of being extended and there is a lot of value in consolidating behavior especially from a quality perspective.