在我的一次采访中,我被要求解释接口类和抽象类之间的区别。
以下是我的回答:
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.
然而,面试官并不满意,他告诉我这种描述代表了“书本知识”。
他让我给出一个更实际的回答,用实际的例子解释我什么时候会选择抽象类而不是接口。
我哪里错了?
我将尝试用实际场景来回答,以说明两者之间的区别。
接口是零负载的,即不需要维护状态,因此将契约(能力)与类关联是更好的选择。
例如,说我有一个执行一些操作的任务类,现在在单独的线程中执行一个任务,我不需要扩展线程类,更好的选择是使任务实现可运行的接口(即实现其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接口和抽象类甚至更窄。
当我试图在两个密切相关的类之间共享行为时,我创建了一个包含公共行为的抽象类,并作为两个类的父类。
当我试图定义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.
是的,从技术上讲,你的回答是正确的,但你的错误之处在于,你没有向他们表明你理解选择其中一个的利弊。此外,他们可能担心将来升级时代码库的兼容性问题。这种类型的回答可能有帮助(除了你说的):
"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."
祝你下次面试好运!
接口是一个“契约”,其中实现契约的类承诺实现方法。举个例子,当我将一款游戏从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;
}
你的所有语句都是有效的,除了你的第一个语句(在Java 8发布之后):
Java接口的方法是隐式抽象的,不能有实现
从文档页:
接口是一种引用类型,类似于类,只能包含
常量、方法签名、默认方法、静态方法和嵌套类型
方法体只存在于默认方法和静态方法中。
默认的方法:
接口可以有默认方法,但与抽象类中的抽象方法不同。
默认方法使您能够向库的接口添加新功能,并确保与为这些接口的旧版本编写的代码的二进制兼容性。
当您扩展一个包含默认方法的接口时,您可以执行以下操作:
完全不要提及默认方法,这将使您的扩展接口继承默认方法。
重新声明默认方法,使其抽象。
重新定义默认方法,该方法将覆盖它。
静态方法:
除了默认方法外,还可以在接口中定义静态方法。静态方法是与定义它的类相关联的方法,而不是与任何对象相关联的方法。类的每个实例都共享它的静态方法。)
这让你更容易在你的库中组织帮助方法;
来自文档页的关于接口具有静态和默认方法的示例代码。
import java.time.*;
public interface TimeClient {
void setTime(int hour, int minute, int second);
void setDate(int day, int month, int year);
void setDateAndTime(int day, int month, int year,
int hour, int minute, int second);
LocalDateTime getLocalDateTime();
static ZoneId getZoneId (String zoneString) {
try {
return ZoneId.of(zoneString);
} catch (DateTimeException e) {
System.err.println("Invalid time zone: " + zoneString +
"; using default time zone instead.");
return ZoneId.systemDefault();
}
}
default ZonedDateTime getZonedDateTime(String zoneString) {
return ZonedDateTime.of(getLocalDateTime(), getZoneId(zoneString));
}
}
使用下面的指导原则来选择是使用接口还是抽象类。
接口:
定义一个契约(最好是无状态的——我的意思是没有变量)
将不相关的类链接到具有一种功能。
声明公共常量变量(不可变状态)
抽象类:
在几个密切相关的类之间共享代码。它建立了一种关系。
在相关类之间共享公共状态(状态可以在具体类中修改)
相关文章:
接口与抽象类(通用面向对象)
实现和扩展:什么时候使用?有什么不同?
通过这些例子,你可以理解
不相关的类可以通过接口具有功能,但相关类通过扩展基类来改变行为。