我先给大家举个例子:

public interface LoginAuth{
   public String encryptPassword(String pass);
   public void checkDBforUser();
}

假设您的应用程序中有3个数据库。然后，该数据库的每个实现都需要定义上述2个方法:

public class DBMySQL implements LoginAuth{
          // Needs to implement both methods
}
public class DBOracle implements LoginAuth{
          // Needs to implement both methods
}
public class DBAbc implements LoginAuth{
          // Needs to implement both methods
}

但是，如果encryptPassword()不依赖于数据库，并且对每个类都是相同的呢?那么上面的方法就不是一个好的方法。

相反，考虑以下方法:

public abstract class LoginAuth{
   public String encryptPassword(String pass){
            // Implement the same default behavior here 
            // that is shared by all subclasses.
   }

   // Each subclass needs to provide their own implementation of this only:
   public abstract void checkDBforUser();
}

现在，在每个子类中，我们只需要实现一个方法——依赖于数据库的方法。

你的解释看起来还不错，但可能看起来像是你从课本上读的?: - /

我更关心的是，你的例子有多可靠?你是否费心去包括抽象和接口之间几乎所有的区别?

就我个人而言，我建议这个链接: http://mindprod.com/jgloss/interfacevsabstract.html#TABLE

对于差异的详尽列表..

希望它能帮助你和所有其他读者在未来的采访

接口是纯粹抽象的。我们在接口中没有任何实现代码。

抽象类包含方法及其实现。

点击这里观看接口和抽象类教程

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

"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."

祝你下次面试好运!

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

当我试图定义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.

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

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

文摘:

例如，我们有一个工资函数，它有一些对所有员工共同的参数。然后我们可以有一个叫做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定义为抽象类，你也可以对抽象类进行这样的强制活动，现在一个扩展抽象类的类仍然是抽象类，直到它覆盖抽象函数。