接口由单例变量(公共静态final)和公共抽象方法组成。当我们知道要做什么但不知道如何做时，我们通常更喜欢实时使用接口。

这个概念可以通过以下例子更好地理解:

考虑一个支付类。支付方式有很多种，比如PayPal，信用卡等。因此，我们通常将Payment作为接口，其中包含makePayment()方法，CreditCard和PayPal是两个实现类。

public interface Payment
{
    void makePayment();//by default it is a abstract method
}
public class PayPal implements Payment
{
    public void makePayment()
    {
        //some logic for PayPal payment
        //e.g. Paypal uses username and password for payment
    }
}
public class CreditCard implements Payment
{
    public void makePayment()
    {
        //some logic for CreditCard payment
        //e.g. CreditCard uses card number, date of expiry etc...
    }
}

在上面的例子中，CreditCard和PayPal是两个实现类/策略。接口还允许我们在Java中实现多重继承的概念，这是抽象类无法实现的。

当我们知道某些特性该做什么，而其他特性又知道如何执行时，我们就会选择一个抽象类。

考虑下面的例子:

public abstract class Burger
{
    public void packing()
    {
        //some logic for packing a burger
    }
    public abstract void price(); //price is different for different categories of burgers
}
public class VegBerger extends Burger
{
    public void price()
    {
        //set price for a veg burger.
    }
}
public class NonVegBerger extends Burger
{
    public void price()
    {
        //set price for a non-veg burger.
    }
}

如果我们将来在给定的抽象类中添加方法(具体的/抽象的)，那么实现类将不需要更改其代码。但是，如果将来在接口中添加方法，则必须将实现添加到实现该接口的所有类中，否则会发生编译时错误。

还有其他不同之处，但这些都是面试官所期望的。希望这对你们有帮助。

在Java中选择接口是为了避免多重继承中的菱形问题。

如果你想让你所有的方法都由你的客户端实现，你可以选择接口。这意味着你要抽象地设计整个应用程序。

如果您已经知道它们的共同点，那么您就可以选择抽象类。例如，取一个抽象类Car。在更高的级别上实现常见的car方法，如calculateRPM()。这是一种常见的方法，你让客户端实现他自己的行为，比如 calculateMaxSpeed()等。也许你会举几个你在日常工作中遇到的真实例子来解释。

这里似乎已经涵盖了几乎所有的东西。在抽象类的实际实现上再补充一点:

Abstract关键字也用于防止类被实例化。如果你有一个具体的类，你不想被实例化-让它抽象。

是的，从技术上讲，你的回答是正确的，但你的错误之处在于，你没有向他们表明你理解选择其中一个的利弊。此外，他们可能担心将来升级时代码库的兼容性问题。这种类型的回答可能有帮助(除了你说的):

"Choosing an Abstract Class over an Interface Class depends on what we project the future of the code will be. Abstract classes allow better forward-compatibility because you can continue adding behavior to an Abstract Class well into the future without breaking your existing code --> this is not possible with an Interface Class. On the other hand, Interface Classes are more flexible than Abstract Classes. This is because they can implement multiple interfaces. The thing is Java does not have multiple inheritances so using abstract classes won't let you use any other class hierarchy structure... So, in the end a good general rule of thumb is: Prefer using Interface Classes when there are no existing/default implementations in your codebase. And, use Abstract Classes to preserve compatibility if you know you will be updating your class in the future."

祝你下次面试好运!

为了让你能在面试中给出一个简单、合理的回答，我提供以下几点:

接口用于为一系列相关类指定API——关系就是接口。通常用于具有多个实现的情况，通过配置或在运行时选择正确的实现。(除非使用Spring，此时接口基本上就是Spring Bean)。接口通常用于解决多重继承问题。

抽象类是专门为继承而设计的类。这也意味着有多个实现，所有实现都有一些共性(在抽象类中可以找到)。

如果你想解决这个问题，那么就说抽象类经常实现接口的一部分——job就是你的了!

当我试图在两个密切相关的类之间共享行为时，我创建了一个包含公共行为的抽象类，并作为两个类的父类。

当我试图定义Type(对象的用户可以可靠地调用的方法列表)时，我创建了一个接口。

例如，我绝不会创建一个只有一个具体子类的抽象类，因为抽象类是关于共享行为的。但是我很可能创建一个只有一个实现的接口。我的代码的用户不会知道只有一个实现。实际上，在未来的版本中可能会有几个实现，它们都是一些新的抽象类的子类，这些抽象类在我创建接口时甚至还不存在。

这似乎也有点太书生气了(尽管我在记忆中从未见过这样的说法)。如果面试官(或OP)真的想要更多关于这方面的个人经验，我早就准备好了关于界面是出于必要而进化的轶事，反之亦然。

One more thing. Java 8 now allows you to put default code into an interface, further blurring the line between interfaces and abstract classes. But from what I have seen, that feature is overused even by the makers of the Java core libraries. That feature was added, and rightly so, to make it possible to extend an interface without creating binary incompatibility. But if you are making a brand new Type by defining an interface, then the interface should be JUST an interface. If you want to also provide common code, then by all means make a helper class (abstract or concrete). Don't be cluttering your interface from the start with functionality that you may want to change.