我最近参加了一次面试，他们问了我一个问题："为什么接口比抽象类更受青睐？"
我尝试给出了几个答案，如下：
他们让我拿出你使用的任何JDBC api。 "为什么它们是接口？"
我可以给出更好的答案吗？
那道面试题反映了提问者的某种信念。我认为他们是错误的，因此你可以选择以下两个方向之一。
他们想要的答案，其他帖子已经很好地强调了那些要点：多接口继承，继承会强制类做出实现选择，接口更易于更改。
然而，如果你在不同意中提出令人信服且正确的论点，面试官可能会注意到。首先，强调接口的优点是必须的。其次，我会说在许多情况下接口更好，但它们也会导致代码重复，这是一个负面因素。如果你有大量的子类将执行大部分相同的实现以及额外的功能，则可能需要使用抽象类。它允许你拥有许多细节相似的对象，而仅使用接口时，你必须具有几个几乎重复的独特对象。
接口有许多用途，并且有令人信服的理由认为它们“更好”。然而，你应该始终使用适合工作的正确工具，这意味着你不能忽视抽象类。
通常而言，这并不是一种应该盲目遵循的“规则”，但最灵活的安排方式是：
interface
abstract class
concrete class 1
concrete class 2
接口存在的原因有以下几点：
这意味着您可以使用预先存在的类（或者必须继承自其他类的类）并使它们与您的代码配合使用。
抽象类提供了所有具体类的公共部分。在编写新类或修改要扩展它的类（假设它们继承自 java.lang.Object）时，需要从抽象类继承。
您应该始终（除非有非常好的理由不这样做）将变量（实例、类、本地和方法参数）声明为接口类型。
继承只有一次机会。如果你创建了一个抽象类而不是接口，那么继承你的类的人不能同时继承另一个抽象类。
你可以实现多个接口，但只能继承一个类。
抽象类
1.不能独立于其派生类实例化。抽象类构造函数仅由其派生类调用。
2.定义了基类必须实现的抽象成员签名。
3.比接口更具可扩展性，且不会破坏任何版本兼容性。使用抽象类，可以添加所有派生类都可以继承的附加非抽象成员。
4.可以包含存储在字段中的数据。
5.允许有（虚拟的）成员具有实现，并因此为派生类提供成员的默认实现。
6.从抽象类派生将使用子类唯一的基类选项。
接口
1.不能被实例化。
2.接口的所有成员实现都在基类中进行。在实现类中只能实现所有成员，而不能仅实现某些成员。
3.扩展接口以添加其他成员会破坏版本兼容性。
4.不能存储任何数据。字段只能在派生类中指定。解决此问题的方法是定义属性，但没有实现。
5.所有成员自动为虚拟的，不能包含任何实现。
6.虽然不能出现默认实现，但实现接口的类仍然可以相互派生。
正如devinb和其他人提到的那样，面试官不接受你的有效答案表明他们的无知。
然而，提到JDBC可能是一个提示。在这种情况下，也许他们正在询问使用接口而不是类编写客户端代码的好处。
因此，与类设计有关的完全有效的答案，例如"您只能使用一次继承"，可能不是他们要寻找的答案，他们可能正在寻找更像"将客户端与特定实现分离"的答案。
super()方法。这可能会导致覆盖类的问题。此外，在继承时使用equals()可能存在潜在问题。当你需要继承实现时，使用抽象类；当你需要继承规范时，使用接口。JDBC标准规定：“连接必须要做这个”。那就是规范。
对于以上大部分帖子，我持有不同意见（抱歉！如果你想的话可以将我降级：-））
首先，“只有一个超类”的答案是无聊的。在面试中给我这个答案的人很快就会被反驳：“C++存在于Java之前，而且C++有多个超类。为什么你认为James Gosling只允许Java有一个超类？”
理解你回答背后的哲学，否则你就完蛋了（至少如果我面试你的话）。
其次，接口比抽象类有多种优势，特别是在设计接口时。最大的优势是不会对方法调用者强加特定的类结构。没有什么比尝试使用要求特定类结构的方法调用更糟糕的了。它很痛苦和尴尬。使用接口，任何东西都可以传递给方法，期望值最小。
例如：
public void foo(Hashtable bar);
对比。
public void foo(Map bar);
public interface FragmentVisitor {
public void visit(Node node);
}
当您使用抽象类时，您创建了子类和基类之间的耦合。随着子类数量的增加，这种耦合有时会使代码变得非常难以更改。接口没有这个问题。
您还只有一个继承，因此您应该确保出于适当的原因使用它。