在我的一次采访中，我被要求解释接口类和抽象类之间的区别。
以下是我的回答:
Methods of a Java interface are implicitly abstract
and cannot have implementations. A Java abstract class can have
instance methods that implements a default behaviour.
Variables declared in a Java interface are by default final. An
abstract class may contain non-final variables.
Members of a Java interface are public by default. A Java abstract
class can have the usual flavours of class members like private,
protected, etc.
A Java interface should be implemented using keyword “implements”; A
Java abstract class should be extended using keyword “extends”.
An interface can extend another Java interface only, an abstract class
can extend another Java class and implement multiple Java interfaces.
A Java class can implement multiple interfaces but it can extend only
one abstract class.
然而，面试官并不满意，他告诉我这种描述代表了“书本知识”。
他让我给出一个更实际的回答，用实际的例子解释我什么时候会选择抽象类而不是接口。
我哪里错了?
接口是一个“契约”，其中实现契约的类承诺实现方法。举个例子，当我将一款游戏从2D升级到3D时，我不得不编写一个界面而不是类。我必须创建一个界面来共享2D和3D版本的游戏类别。
package adventure;
import java.awt.*;
public interface Playable {
public void playSound(String s);
public Image loadPicture(String s);
}
然后我可以实现基于环境的方法，同时仍然能够从一个不知道正在加载的游戏版本的对象调用这些方法。
公共类Adventure扩展了JFrame实现了Playable
公共类Dungeon3D扩展了SimpleApplication实现的Playable
公共类Main扩展了SimpleApplication实现了AnimEventListener
ActionListener,播放
通常，在游戏世界中，世界可以是一个抽象类，在游戏中执行方法:
public abstract class World...
public Playable owner;
public Playable getOwner() {
return owner;
}
public void setOwner(Playable owner) {
this.owner = owner;
}
我将尝试用实际场景来回答，以说明两者之间的区别。
接口是零负载的，即不需要维护状态，因此将契约(能力)与类关联是更好的选择。
例如，说我有一个执行一些操作的任务类，现在在单独的线程中执行一个任务，我不需要扩展线程类，更好的选择是使任务实现可运行的接口(即实现其run()方法)，然后将此任务类的对象传递给线程实例并调用其start()方法。
现在你可以问，如果Runnable是一个抽象类呢?
从技术上讲，这是可能的，但从设计角度来看，这是一个糟糕的选择原因:
Runnable没有与之相关的状态，也没有“提供”任何状态
run()方法的默认实现
Task必须扩展它，因此它不能扩展任何其他类
Task没有提供任何专门化到Runnable类，它所需要的只是重写run()方法
换句话说，Task类需要在线程中运行的能力，这是通过实现Runnable接口而实现的，而扩展thread类则使其成为线程。
简单地把我们的接口定义为一种能力(契约)，而使用
的抽象类，用于定义的框架(公共/部分)实现
它。
免责声明:下面是愚蠢的例子，尽量不要判断:-P
interface Forgiver {
void forgive();
}
abstract class GodLike implements Forgiver {
abstract void forget();
final void forgive() {
forget();
}
}
现在你可以选择成为神一样的人，但你可以选择只成为宽恕者(即不成为神一样的人)，并做:
class HumanLike implements Forgiver {
void forgive() {
// forgive but remember
}
}
或者你可以选择像上帝一样去做:
class AngelLike extends GodLike {
void forget() {
// forget to forgive
}
}
P.S.与java 8接口也可以有静态以及默认(可重写实现)方法，因此区别b/w接口和抽象类甚至更窄。
是的，从技术上讲，你的回答是正确的，但你的错误之处在于，你没有向他们表明你理解选择其中一个的利弊。此外，他们可能担心将来升级时代码库的兼容性问题。这种类型的回答可能有帮助(除了你说的):
"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."
祝你下次面试好运!
