我最近接受了两次电话采访,被问及接口类和抽象类之间的区别。我已经解释了我能想到的每一个方面,但似乎他们在等我提一些具体的事情,我不知道是什么。

根据我的经验,我认为以下是正确的。如果我遗漏了一个要点,请告诉我。

接口:

接口中声明的每个方法都必须在子类中实现。接口中只能存在事件、委托、财产(C#)和方法。一个类可以实现多个接口。

抽象类:

子类只能实现抽象方法。抽象类可以具有具有实现的普通方法。除了事件、委托、财产和方法之外,抽象类还可以有类变量。由于C#中不存在多重继承,一个类只能实现一个抽象类。

在这之后,面试官提出了一个问题:“如果你有一个只有抽象方法的抽象类呢?这和接口有什么不同?”我不知道答案,但我认为这是上面提到的继承,对吧?另一位面试官问我,“如果你在接口中有一个公共变量,那会和抽象类中有什么不同?”我坚持认为你不能在接口中使用公共变量。我不知道他想听什么,但他也不满意。

另请参阅:

何时使用接口而不是抽象类,反之亦然接口与抽象类如何决定使用抽象类和接口?接口和抽象类之间的区别是什么?


当前回答

我将解释接口和抽象类的深度细节。如果您了解接口和抽象类别的概述,那么第一个问题就会出现在您的脑海中,我们应该何时使用接口,何时使用抽象类别。因此,请检查以下接口和抽象类的说明。

我们什么时候应该使用界面?如果您不了解实现,我们只有需求规范,那么我们就使用Interface我们什么时候应该使用抽象类?如果您知道实现但不完全(部分实现),那么我们使用抽象类。界面默认情况下,每个方法的公共抽象意味着接口是100%纯抽象的。摘要可以有Concrete方法和Abstract方法,抽象类是一个声明为抽象的类,它可以包含也可以不包含抽象方法。界面我们不能将接口声明为私有的、受保护的问:为什么我们不将接口声明为私有和受保护的?因为默认情况下接口方法是公共抽象的,所以我们没有将接口声明为私有和受保护的。接口方法我们也不能将接口声明为private、protected、final、static、synchronized、native。。。。。我会给出原因:为什么我们不声明synchronized方法,因为我们无法创建接口的对象,而synchronization是在对象上工作的,这也是我们不声明synchronized的原因瞬态概念也不适用,因为瞬态工作与同步。摘要我们很乐意使用公共的、私人的最终静态。。。。表示抽象上不适用任何限制。界面默认情况下,变量在接口中声明为公共静态final,因此我们也不会将变量声明为私有的受保护变量。易失性修饰符也不适用于接口,因为接口变量默认为公共静态final和final变量。一旦它将值分配给变量,您就不能更改该值,一旦您将变量声明给接口,您就必须分配该变量。易失性变量是不断变化的,所以它是最后一个,这就是我们不在接口中使用易失性的原因。摘要抽象变量不需要声明公共静态final。

我希望这篇文章有用。

其他回答

虽然您的问题表明它是针对“通用OO”的,但它似乎真正关注的是.NET对这些术语的使用。

在.NET中(类似于Java):

接口可以没有状态或实现实现接口的类必须提供该接口的所有方法的实现抽象类可以包含状态(数据成员)和/或实现(方法)抽象类可以在不实现抽象方法的情况下继承(尽管这样的派生类本身是抽象的)接口可能是多继承的,抽象类可能不是(这可能是接口与abtract类分开存在的关键具体原因——它们允许实现多继承,从而消除了一般MI的许多问题)。

作为通用OO术语,差异不一定定义明确。例如,有些C++程序员可能持有类似的严格定义(接口是抽象类的严格子集,不能包含实现),而有些人可能会说,具有某些默认实现的抽象类仍然是接口,或者非抽象类仍然可以定义接口。

事实上,有一种叫做非虚拟接口(NVI)的C++习惯用法,其中公共方法是“thunk”到私有虚拟方法的非虚拟方法:

http://www.gotw.ca/publications/mill18.htmhttp://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-虚拟界面(_I)

我认为他们不喜欢你的回应,因为你给出的是技术上的差异,而不是设计上的差异。对我来说,这个问题就像一个巨魔问题。事实上,接口和抽象类有着完全不同的性质,所以你无法真正比较它们。我将向您介绍接口的作用和抽象类的作用。

接口:用于确保契约和类之间的低耦合,以获得更可维护、可扩展和可测试的应用程序。

抽象类:仅用于在具有相同响应性的类之间分解某些代码。请注意,这是为什么多重继承在OOP中是一件坏事的主要原因,因为类不应该处理许多响应(而是使用组合)。

因此,接口具有真正的体系结构角色,而抽象类几乎只是实现的一个细节(当然,如果正确使用的话)。

Jeffrey Richter通过C#从CLR复制。。。

我经常听到这样一个问题,“我应该设计一个基类型还是一个接口?”答案并不总是清晰明了。

以下是一些可能对您有所帮助的指南:

■■ IS-A与CAN-DO关系A类型只能继承一个实现。如果导出类型不能声明与基类型的IS-A关系,不要使用基类型;使用接口。接口意味着CAN-DO关系。如果CAN-DO功能似乎属于对于各种对象类型,使用接口。例如,类型可以转换自身的实例类型可以将其自身的实例序列化(ISerializable),注意,值类型必须从System.ValueType派生,因此不能可以从任意基类派生。在这种情况下,您必须使用CAN-DO关系并定义接口。

■■ 易用性作为开发人员,定义从基类型,而不是实现接口的所有方法。基本类型可以提供许多功能,因此派生类型可能只需要对其行为进行相对较小的修改。如果提供接口,则新类型必须实现所有成员。

■■ 一致的实施无论接口合同记录得多么好每个人都不可能100%正确地履行合同。事实上,COM这就是为什么某些COM对象只能与微软Word或Windows Internet Explorer。通过为基础类型提供默认实现,您首先使用一种有效且经过良好测试的类型;那么你可以修改需要修改的零件。

■■ 版本控制如果向基类型添加方法,则派生类型继承新方法,您开始使用一种有效的类型,用户的源代码甚至不必重新编译。向接口添加新成员将强制接口的继承者更改它的源代码并重新编译。

接口:如果您希望在组件上暗示规则,则应使用该接口彼此相关的

赞成的意见:

允许多重继承通过不公开上下文中使用的确切类型的对象来提供抽象通过合同的特定签名提供一致性

欺骗:

必须执行所有定义的合同不能有变量或委托一旦定义,就不能在不破坏所有类的情况下进行更改

抽象类:应用于希望对彼此相关的组件具有一些基本或默认行为或实现的情况

赞成的意见:

比接口更快在实施中具有灵活性(您可以完全或部分实施)可以在不破坏派生类的情况下轻松更改

欺骗:

无法实例化不支持多重继承

这些答案太长了。

接口用于定义行为。抽象类用于定义事物本身,包括其行为。这就是为什么我们有时会创建一个抽象类,其中包含一些继承接口的额外财产。

这也解释了为什么Java只支持类的单一继承,而不限制接口。因为一个具体的对象不可能是不同的东西,但它可以有不同的行为。