Many junior developers make the mistake of thinking of interfaces, abstract and concrete classes as slight variations of the same thing, and choose one of them purely on technical grounds: Do I need multiple inheritance? Do I need some place to put common methods? Do I need to bother with something other than just a concrete class? This is wrong, and hidden in these questions is the main problem: "I". When you write code for yourself, by yourself, you rarely think of other present or future developers working on or with your code.

接口和抽象类，虽然从技术的角度来看很相似，但它们的含义和目的完全不同。

总结

接口定义了一个契约，由某个实现为您实现。 抽象类提供了您的实现可以重用的默认行为。

以上两点正是我在面试时所寻求的，并且是一个足够紧凑的总结。阅读更多细节。

替代的总结

接口用于定义公共api 抽象类用于内部使用和定义spi

通过例子

To put it differently: A concrete class does the actual work, in a very specific way. For example, an ArrayList uses a contiguous area of memory to store a list of objects in a compact manner which offers fast random access, iteration, and in-place changes, but is terrible at insertions, deletions, and occasionally even additions; meanwhile, a LinkedList uses double-linked nodes to store a list of objects, which instead offers fast iteration, in-place changes, and insertion/deletion/addition, but is terrible at random access. These two types of lists are optimized for different use cases, and it matters a lot how you're going to use them. When you're trying to squeeze performance out of a list that you're heavily interacting with, and when picking the type of list is up to you, you should carefully pick which one you're instantiating.

On the other hand, high level users of a list don't really care how it is actually implemented, and they should be insulated from these details. Let's imagine that Java didn't expose the List interface, but only had a concrete List class that's actually what LinkedList is right now. All Java developers would have tailored their code to fit the implementation details: avoid random access, add a cache to speed up access, or just reimplement ArrayList on their own, although it would be incompatible with all the other code that actually works with List only. That would be terrible... But now imagine that the Java masters actually realize that a linked list is terrible for most actual use cases, and decided to switch over to an array list for their only List class available. This would affect the performance of every Java program in the world, and people wouldn't be happy about it. And the main culprit is that implementation details were available, and the developers assumed that those details are a permanent contract that they can rely on. This is why it's important to hide implementation details, and only define an abstract contract. This is the purpose of an interface: define what kind of input a method accepts, and what kind of output is expected, without exposing all the guts that would tempt programmers to tweak their code to fit the internal details that might change with any future update.

抽象类介于接口和具体类之间。它应该帮助实现共享常见或无聊的代码。例如，AbstractCollection提供了基于大小为0的isEmpty的基本实现，contains作为迭代和比较，addAll作为重复添加，等等。这使得实现将重点放在区分它们的关键部分:如何实际存储和检索数据。

另一个角度:api与spi

接口是代码不同部分之间的低内聚网关。它们允许库的存在和发展，而不会在内部发生变化时影响到每个库的用户。它被称为应用程序编程接口，而不是应用程序编程类。在较小的规模上，它们还允许多个开发人员在大型项目上成功协作，通过良好的文档接口分离不同的模块。

抽象类是在实现接口时使用的高内聚帮助器，假设有某种级别的实现细节。或者，抽象类用于定义服务提供者接口(spi)。

API和SPI之间的区别很微妙，但很重要:对于API，重点在于谁使用它，而对于SPI，重点在于谁实现它。

Adding methods to an API is easy, all existing users of the API will still compile. Adding methods to an SPI is hard, since every service provider (concrete implementation) will have to implement the new methods. If interfaces are used to define an SPI, a provider will have to release a new version whenever the SPI contract changes. If abstract classes are used instead, new methods could either be defined in terms of existing abstract methods, or as empty throw not implemented exception stubs, which will at least allow an older version of a service implementation to still compile and run.

关于Java 8和默认方法的说明

尽管Java 8为接口引入了默认方法，这使得接口和抽象类之间的界限更加模糊，但这并不是为了实现可以重用代码，而是为了更容易地更改既作为API又作为SPI(或者被错误地用于定义SPI而不是抽象类)的接口。

“书本知识”

OP回答中提供的技术细节被认为是“书本知识”，因为这通常是在学校和大多数关于语言的技术书籍中使用的方法:一个东西是什么，而不是如何在实践中使用它，特别是在大规模应用中。

打个比方:假设问题是:

舞会之夜租什么更好，一辆车还是一间酒店房间?

技术上的答案是这样的:

嗯，在车里你可以做得更快，但在酒店房间里你可以做得更舒服。另一方面，酒店房间只在一个地方，而在汽车里你可以在更多的地方这样做，比如，你可以去远景点看风景，或者在汽车电影院，或者很多其他地方，甚至不止一个地方。而且，酒店房间里有淋浴。

这都是真的，但完全忽略了一点，那就是它们是两种完全不同的东西，两者都可以同时用于不同的目的，“做”方面并不是这两种选择中最重要的事情。这个答案缺乏视角，它显示了一种不成熟的思维方式，而正确地呈现了真实的“事实”。

我为工作做面试，我也会不看好你的答案(抱歉，但我很诚实)。听起来你确实读过不同之处并修改了答案，但也许你从未在实践中使用过。

一个好的解释为什么你会使用每一种，比一个精确的解释差异要好得多。雇主最终希望程序员做一些他们不了解的事情，而这些事情很难在面试中展示出来。如果你申请的是技术或文档相关的工作，而不是开发人员的职位，你给出的答案会很好。

祝你以后面试顺利。

另外，我对这个问题的回答更多的是关于面试技巧，而不是你提供的技术材料。或许可以考虑读一读。https://workplace.stackexchange.com/是做这类事情的好地方。

在抽象类中，可以编写方法的默认实现!但是在Interface中你不能。基本上，在接口中存在纯虚方法，这些方法必须由实现接口的类来实现。

接口由单例变量(公共静态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.
    }
}

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

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

嗯，现在人们渴望实用的方法，你说得很对，但大多数面试官看起来是按照他们目前的要求，想要一个实用的方法。

回答完你的问题后，你应该跳到例子上:

文摘:

例如，我们有一个工资函数，它有一些对所有员工共同的参数。然后我们可以有一个叫做CTC的抽象类，它带有部分定义的方法体，它将被所有类型的员工扩展，并根据他们的额外工资得到补偿。 对于公共功能。

public abstract class CTC {

    public int salary(int hra, int da, int extra)
    {
        int total;
        total = hra+da+extra;
        //incentive for specific performing employee
        //total = hra+da+extra+incentive;
        return total;
    }
}

class Manger extends CTC
{
}


class CEO extends CTC
{
}

class Developer extends CTC
{   
}

接口

Java中的接口允许在不扩展接口功能的情况下拥有接口功能，你必须清楚你想在应用程序中引入的功能签名的实现。它会迫使你做出定义。 不同的功能。

public interface EmployeType {

    public String typeOfEmployee();
}

class ContarctOne implements EmployeType
{

    @Override
    public String typeOfEmployee() {
        return "contract";
    }

}

class PermanentOne implements EmployeType
{

    @Override
    public String typeOfEmployee() {
        return "permanent";
    }

}

通过将methgos定义为抽象类，你也可以对抽象类进行这样的强制活动，现在一个扩展抽象类的类仍然是抽象类，直到它覆盖抽象函数。

接口就像一组公开记录的具有某种影响的基因:DNA测试会告诉我是否有它们——如果我有，我可以公开让人们知道我是“携带者”，我的部分行为或状态将符合它们。(当然，我可能还有很多其他基因，这些基因提供的特征超出了这个范围。)

抽象类就像单性别物种的死去的祖先(*):她不能被复活，但一个活着的(即非抽象的)后代继承了她所有的基因。

为了扩展这个比喻，我们假设这个物种的所有成员都活到相同的年龄。这意味着一个死去的祖先的所有祖先也必须是死的——同样，一个活着的祖先的所有后代也必须是活着的。