这可能是一个通用的OOP问题。我想在接口和抽象类的使用基础上做一个通用的比较。

什么时候需要使用接口,什么时候需要使用抽象类?


当前回答

如果你认为java是面向对象语言,

“接口不提供方法实现”在Java 8启动后不再有效。现在java为默认方法提供了接口实现。

简单来说,我想用

接口:通过多个不相关的对象实现一个契约。它提供了“HAS A”功能。

抽象类:在多个相关对象之间实现相同或不同的行为。它建立了“IS A”关系。

Oracle网站提供了接口和抽象类之间的关键区别。

考虑使用抽象类,如果:

您希望在几个密切相关的类之间共享代码。 您希望扩展抽象类的类具有许多公共方法或字段,或者需要除public以外的访问修饰符(例如protected和private)。 您希望声明非静态或非final字段。

考虑使用接口,如果:

您希望不相关的类实现您的接口。例如,许多不相关的对象都可以实现Serializable接口。 您希望指定特定数据类型的行为,但不关心由谁实现其行为。 您希望利用类型的多重继承。

例子:

抽象类(IS一个关系)

Reader是一个抽象类。

BufferedReader是一个Reader

FileReader是一个阅读器

FileReader和BufferedReader用于一个共同的目的:读取数据,它们通过Reader类相互关联。

接口(具有功能)

Serializable是一个接口。

假设您的应用程序中有两个实现Serializable接口的类

Employee实现Serializable

游戏实现Serializable

在这里,你不能通过Serializable接口在员工和游戏之间建立任何关系,这是为了不同的目的。两者都能够序列化状态,比较到此结束。

看看这些帖子:

我应该如何解释接口和抽象类之间的区别?

其他回答

两者都是类定义的契约:

结论1:两种意图都是对象泛化

在定义抽象类时,它们也可以有默认实现。

结论2:区分存在于行为泛化设计中

在使用抽象类时,类只能从一个抽象类继承

结论3:抽象类在应用上存在局限性。它的意思是 行为概括的局限性。

最后结论-何时使用哪个:区分是在行为泛化层面

在类的行为设计中,如果功能在确定的类之间只是概念上的限制,换句话说,在确定的类之间是共享的,则使用抽象类。但如果功能比确定类更通用,或者我们可以/想要向其他类添加功能,则使用接口作为契约。

这是一个很难打的电话。

我可以给出一个提示:一个对象可以实现许多接口,而一个对象只能继承一个基类(在像c#这样的现代OO语言中,我知道c++有多个继承-但这不是不受欢迎吗?)

纯粹在继承的基础上,你可以使用一个抽象的定义清晰的后代,抽象的关系(例如动物->猫)和/或需要继承虚拟或非公共属性,特别是共享状态(接口不支持)。

你应该尝试使用组合(通过依赖注入)而不是继承,并且注意接口作为契约支持单元测试、关注点分离和(语言变化)多重继承,而抽象则不能。

什么时候做什么是一件非常简单的事情,如果你有清晰的概念在你的脑海里。

抽象类可以是派生类,而接口可以是实现类。这两者之间有一些区别。当派生抽象类时,派生类和基类之间的关系是“is a”关系。例如,狗是动物,羊是动物,这意味着派生类从基类继承了一些属性。

而对于接口的实现,关系是“可以是”。例:狗可以是间谍犬。狗可以是马戏团的狗。狗可以是比赛犬。这意味着你要实现特定的方法来获取某些东西。

我希望我讲清楚了。

好吧,我自己刚刚“grokup”了这个——这是外行的术语(如果我错了,请随意纠正我)——我知道这个话题太老了,但其他人可能有一天会偶然发现它……

抽象类允许你创建一个蓝图,并允许你额外构造(实现)属性和方法,你希望它的所有后代都拥有。

另一方面,接口只允许您声明希望在实现它的所有类中存在具有给定名称的属性和/或方法——但不指定应该如何实现它。同样,一个类可以实现许多接口,但只能扩展一个抽象类。界面更像是一种高级架构工具(如果你开始掌握设计模式,这一点就会变得更清楚)——抽象则同时涉足这两个阵营,也可以执行一些繁琐的工作。

为什么使用其中一种而不是另一种呢?前者允许对后代进行更具体的定义,而后者允许更大的多态性。最后一点对最终用户/编码器很重要,他们可以利用这些信息以各种组合/形状来实现A.P.I(界面),以满足他们的需求。

我认为这对我来说是一个“顿悟”的时刻——少从作者的角度来考虑接口,多从后面加入到项目中实现或扩展API的编码器的角度来考虑接口。