接口与抽象类（一般面向对象）

Question

我最近接受了两次电话采访，被问到接口和抽象类之间的区别。 我已经把我能想到的各个方面都解释了，但他们似乎在等我说一些具体的东西，而我也不知道那是什么。

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

接口：

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

抽象类：

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

1. 毕竟，面试官提出了这样的问题：“如果你有一个只有抽象方法的抽象类怎么办？这与接口有什么不同？” 我不知道答案，但我认为这是上面提到的继承，对吗？

2. 另一位面试官问我：“如果接口中有一个 Public 变量，这与抽象类中有什么不同？” 我坚持认为接口中不能有公共变量。 我不知道他想听什么，但他也不满意。

另请参阅：

• 何时使用接口而不是抽象类，反之亦然

• 接口与抽象类< /p>

• 您如何决定使用抽象类和接口？< /p>

• 接口和抽象类有什么区别？

Answer 1

打个比方：当我在空军时，我参加了飞行员培训并成为一名 USAF（美国空军）飞行员。 那时我没有资格驾驶任何东西，必须参加飞机型号培训。 获得资格后，我成为一名飞行员（抽象类）和 C-141 飞行员（具体类）。 在我的一项任务中，我被赋予了一项额外职责：安全官。 现在我仍然是一名飞行员和 C-141 飞行员，但我还履行安全官职责（可以说，我实施了 ISafetyOfficer）。 飞行员不需要成为安全官员，其他人也可以这样做。

所有美国空军飞行员都必须遵守某些空军范围内的规定，所有 C-141（或 F-16 或 T-38）飞行员“都是”美国空军飞行员。 任何人都可以成为安全员。 因此，总结一下：

• Pilot：抽象类
• C-141 Pilot：具体类
• ISafety 官员：接口

添加注释：这是一个帮助解释概念的类比，而不是编码建议。 看看下面的各种评论，讨论很有趣。

Answer 2

虽然您的问题表明它是针对“一般 OO”，但它似乎确实关注这些术语的 .NET 使用。

在 .NET 中（与 Java 类似）：

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

作为一般的面向对象术语，这些差异不一定是明确定义的。 例如，有些 C++ 程序员可能持有类似的严格定义（接口是不能包含实现的抽象类的严格子集），而有些人可能会说具有某些默认实现的抽象类仍然是一个接口，或者是一个非抽象类。类仍然可以定义接口。

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

• http://www.gotw.ca/publications/mill18.htm
• http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-Virtual_Interface

Answer 3

我认为他们正在寻找的答案是根本的或 OPPS 哲学差异。

当派生类共享抽象类的核心属性和行为时，使用抽象类继承。 实际定义类的行为类型。

另一方面，当类共享外围行为（不一定定义派生类）时，使用接口继承。

例如。 汽车和卡车共享汽车抽象类的许多核心属性和行为，但它们也共享一些外围行为，例如生成排气，甚至非汽车类（例如钻机或发电机）也共享这些行为，并且不一定定义汽车或卡车，因此汽车、卡车、钻机和发电机都可以共享相同的接口 IExhaust。

Answer 4

简而言之：抽象类用于建模类似外观类的类层次结构（例如 Animal 可以是抽象类，Human、Lion、Tiger 可以是具体的派生类）

并且

Interface 用于 2个相似/不相似的类之间的通信，不关心实现接口的类的类型（例如，高度可以是接口属性，它可以由人类，建筑，树来实现。如果你能吃东西并不重要，你可以游泳，你可以死或任何东西......这只是你需要有高度（在你的班级中实现）的事情。

Answer 5

还有一些其他差异 -

接口不能有任何具体的实现。 抽象基类可以。 这允许您在那里提供具体的实现。 这可以允许抽象基类实际上提供更严格的契约，而接口实际上仅描述类的使用方式。 （抽象基类可以具有定义行为的非虚拟成员，这为基类作者提供了更多控制权。）

一个类可以实现多个接口。 一个类只能从一个抽象基类派生。 这允许使用接口的多态层次结构，但不允许使用抽象基类。 这还允许使用接口进行伪多重继承。

可以在 v2+ 中修改抽象基类，而不会破坏 API。 界面的改变是破坏性的改变。

[C#/.NET 特定] 与抽象基类不同，接口可以应用于值类型（结构）。 结构不能从抽象基类继承。 这允许将行为契约/使用指南应用于价值类型。

Answer 6

继承
考虑一辆汽车和一辆公共汽车。 它们是两种不同的车辆。 但它们仍然有一些共同的特性，比如它们有转向、刹车、齿轮、发动机等。
因此，通过继承概念，这可以表示为以下内容......

public class Vehicle {
    private Driver driver;
    private Seat[] seatArray; //In java and most of the Object Oriented Programming(OOP) languages, square brackets are used to denote arrays(Collections).
    //You can define as many properties as you want here ...
}

现在是一辆自行车......

public class Bicycle extends Vehicle {
    //You define properties which are unique to bicycles here ...
    private Pedal pedal;
}

还有一辆汽车......

public class Car extends Vehicle {
    private Engine engine;
    private Door[] doors;
}

这就是继承。 正如我们上面所看到的，我们使用它们将对象分类为更简单的基本形式及其子形式。

抽象类

抽象类是不完整对象。 为了进一步理解它，让我们再次考虑车辆的类比。
可以驾驶车辆。 正确的？ 但不同的车辆以不同的方式驾驶......例如，你不能像驾驶自行车一样驾驶汽车。
那么如何表示车辆的驱动功能呢？ 更难检查它是什么类型的车辆并以其自身的功能驾驶它； 添加新类型的车辆时，您必须一次又一次地更改 Driver 类。
这就说到了抽象类和方法的作用。 您可以将drive方法定义为抽象方法，以告诉每个继承的孩子必须实现此功能。
因此，如果您修改车辆类别...

//......Code of Vehicle Class
abstract public void drive();
//.....Code continues

Bicycle 和 Car 也必须指定如何驾驶它。 否则，代码将无法编译并引发错误。
简而言之......抽象类是一个部分不完整的类，具有一些不完整的功能，继承的子类必须指定自己的功能。

接口
接口完全不完整。 他们没有任何属性。 它们只是表明继承的孩子有能力做某事......
假设您有不同类型的手机。 他们每个人都有不同的方式来完成不同的功能； 例如：给一个人打电话。 手机制造商指定了如何操作。 这里手机可以拨打号码——即可以拨打。 让我们将其表示为一个接口。

public interface Dialable {
    public void dial(Number n);
}

这里 Dialable 的制造商定义了如何拨打号码。 您只需给它一个号码即可拨打。

// Makers define how exactly dialable work inside.

Dialable PHONE1 = new Dialable() {
    public void dial(Number n) {
        //Do the phone1's own way to dial a number
    }
}

Dialable PHONE2 = new Dialable() {
    public void dial(Number n) {
        //Do the phone2's own way to dial a number
    }
}


//Suppose there is a function written by someone else, which expects a Dialable
......
public static void main(String[] args) {
    Dialable myDialable = SomeLibrary.PHONE1;
    SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....

通过使用接口而不是抽象类，使用 Dialable 的函数的编写者不必担心它的属性。 例如：它是否有触摸屏或拨号盘，是固定电话还是移动电话。 您只需要知道它是否可拨号即可； 它是否继承（或实现）Dialable 接口。

更重要的是，如果有一天您将 Dialable 切换为另一个，

......
public static void main(String[] args) {
    Dialable myDialable = SomeLibrary.PHONE2; // <-- changed from PHONE1 to PHONE2
    SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....

您可以确定代码仍然可以完美运行，因为使用 dialable 的函数不会（也不能）依赖于除那些在Dialable 接口中指定的。 它们都实现了 Dialable 接口，这是该函数唯一关心的事情。

开发人员通常使用接口来确保对象之间的互操作性（可互换使用），只要它们共享共同的功能（就像您可以更改为固定电话或移动电话，只要您只需要拨打一个号码）。 简而言之，接口是抽象类的简单版本，没有任何属性。
另请注意，您可以实现（继承）任意数量的接口，但只能扩展（继承）单个父类。

更多信息
抽象类与接口

Answer 7

这些答案都太长了。

• 接口用于定义行为。

• 抽象类用于定义事物本身，包括其行为。 这就是为什么我们有时会创建一个带有一些继承接口的额外属性的抽象类。

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

Answer 8

采访者们正在对一棵奇怪的树咆哮。 对于 C# 和 Java 等语言，存在差异，但在 C++ 等其他语言中则没有差异。 面向对象理论并不区分两者，只是区分语言的语法。

抽象类是同时具有将被继承的实现和接口（纯虚方法）的类。 接口通常没有任何实现，只有纯虚函数。

在 C# 或 Java 中，没有任何实现的抽象类与接口的不同之处仅在于用于继承它的语法以及只能从一个接口继承这一事实。

Answer 9

通过实现接口，您可以实现组合（“has-a”关系）而不是继承（“is-a”关系）。 当涉及到设计模式之类的事情时，这是一个需要记住的重要原则，在设计模式中，您需要使用接口来实现行为组合而不是继承。

Answer 10

从概念上讲，保持语言特定的实现、规则、好处，并通过使用任何人或两者来实现任何编程目标，可以或不能有代码/数据/属性，等等，单继承或多继承，全部放在一边

1-抽象（或纯抽象） ) 类的目的是实现层次结构。 如果您的业务对象在结构上看起来有些相似，表示父子（层次结构）类型的关系，那么才会使用继承/抽象类。 如果您的业务模型没有层次结构，则不应使用继承（这里我不是在谈论编程逻辑，例如某些设计模式需要继承）。 从概念上讲，抽象类是 OOP 中实现业务模型层次结构的一种方法，它与接口无关，实际上将抽象类与接口进行比较是没有意义的，因为两者在概念上是完全不同的东西，在面试中被要求只是为了检查概念，因为在实现方面，它们看起来都提供了一些相同的功能，而我们程序员通常更强调编码。 [还要记住，抽象与抽象类不同]。

2- 接口是一种契约，是由一组或多组功能表示的完整业务功能。 这就是为什么它是被实现而不是被继承的。 业务对象（无论是否属于层次结构的一部分）可以具有任意数量的完整业务功能。 它与抽象类无关，抽象类意味着一般的继承。 例如，人可以RUN，大象可以RUN，鸟可以RUN等等，所有这些不同层次的对象都将实现RUN接口或EAT或SPEAK接口。 不要进入实现，因为您可能会将其实现为为实现这些接口的每种类型提供抽象类。 任何层次结构的对象都可以具有与其层次结构无关的功能（接口）。

我相信，接口不是为了实现多重继承或公开公共行为而发明的，同样，纯抽象类也不是为了推翻接口，而是接口是对象可以执行的功能（通过该接口的函数），而抽象类代表一个层次结构的父级产生具有父级核心结构（属性+功能）的子级

当您被问及差异时，它实际上是概念上的差异，而不是特定于语言的实现中的差异，除非明确询问。

我相信，两位面试官都期望这两者之间有一个直接的区别，当你失败时，他们试图通过将一个作为另一个来驱使你走向这一差异

如果您有一个仅包含抽象方法的抽象类怎么办？

Answer 11

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

1. 什么时候应该使用接口？

   如果您不了解实现，只是我们有需求规范，那么我们就使用接口

2. 什么时候应该使用抽象类？

   如果您知道实现但不完全（部分实现），那么我们使用抽象类。

   界面

   默认情况下，每个方法都是公共抽象，意味着接口是 100% 纯抽象。

   摘要

   可以有具体方法和抽象方法，什么是具体方法，具体方法在抽象类中有实现，
   抽象类是被声明为抽象的类，它可能包含抽象方法，也可能不包含抽象方法。

   界面

   我们不能将接口声明为私有的、受保护的

   问。 为什么我们不将接口声明为私有且受保护的？

   因为默认情况下接口方法是公共抽象的，所以我们没有将接口声明为私有和受保护的。

   接口方法
   我们也不能将接口声明为 private、protected、final、static、synchronized、native...

   我会给出原因：
   为什么我们没有声明同步方法，因为我们无法创建接口对象，并且同步是在对象上工作的，所以我们没有声明同步方法的原因
   瞬态概念也不适用，因为瞬态与同步一起工作。

   摘要

   我们很乐意与公共、私有最终静态一起使用......意味着抽象中没有适用的限制。

   界面

   默认情况下，变量在接口中声明为公共静态最终变量，因此我们也没有将变量声明为私有、受保护的变量。

   Volatile 修饰符也不适用于接口，因为接口变量默认是 public static Final 和 Final 变量，一旦将值分配给变量，您就无法更改该值，并且一旦将变量声明到接口中，您必须分配该变量。< /p>

   并且 volatile 变量会不断变化，所以它是 opp。 到final，这就是我们不在接口中使用易失性变量的原因。

   摘要

   抽象变量不需要声明 public static final。

我希望这篇文章有用。

Answer 12

对于.Net，

您对第二个面试官的回答也是对第一个面试官的回答...抽象类可以有实现，并且状态，接口不能...

编辑：在另一个注释中，我什至不会使用短语'子类”（或“继承”短语）来描述“定义为实现”接口的类。 对我来说，接口是一个契约的定义，如果类被定义为“实现”该接口，则该类必须遵守该契约。 它不会继承任何东西...您必须自己显式地添加所有内容。

Answer 13

接口：如果你想在组件上暗示一条规则，该规则可能是也可能不是，则应该使用
彼此相关

优点：

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

缺点：

1. 必须实现所有定义的契约
2. 不能有变量或委托
3. 一旦定义就不能在不破坏所有类的情况下进行更改

抽象类：应该在您想要一些基本或默认值的地方使用彼此相关的组件的行为或实现

优点：

1. 比接口更快
2. 实现具有灵活性（您可以完全或部分实现它）
3. 可以轻松更改，而不会破坏派生类

缺点：< /strong>

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

Answer 14

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

接口：用于确保契约并在类之间实现低耦合，以便拥有更可维护、可扩展和可测试的应用程序。

抽象类：仅用于分解具有相同职责的类之间的一些代码。 请注意，这是 OOP 中多重继承是一件坏事的主要原因，因为 类不应该处理许多职责（使用组合代替）。

因此，接口具有真正的架构作用，而抽象类几乎只是实现的细节（当然，如果你正确使用它的话）。

Answer 15

1. 界面：
   • 我们不实现（或定义）方法，而是在派生类中实现。
   • 我们不在接口中声明成员变量。
   • 接口表达了HAS-A关系。 这意味着它们是物体的面具。
2. 抽象类：
   • 我们可以在抽象类中声明和定义方法。
   • 我们隐藏它的构造函数。 这意味着没有直接从它创建的对象。
   • 抽象类可以保存成员变量。
   • 派生类继承到抽象类，这意味着派生类的对象不会被屏蔽，而是继承到抽象类。 本例中的关系是 IS-A。

这是我的意见。

Answer 16

After all that, the interviewer came up with the question "What if you had an 
Abstract class with only abstract methods? How would that be different
from an interface?" 

Docs明确指出，如果抽象类只包含抽象方法声明，则应该声明它作为一个接口。

An another interviewer asked me what if you had a Public variable inside
the interface, how would that be different than in Abstract Class?

接口中的变量默认是公共静态和最终的。 问题可以这样设计：如果抽象类中的所有变量都是公共的怎么办？ 与接口中的变量不同，它们仍然可以是非静态和非最终的。

最后，我想对上面提到的内容再补充一点——抽象类仍然是类，并且属于单个继承树，而接口可以存在于多重继承中。

Answer 17

太长；博士； 当您看到“Is A”关系时，请使用继承/抽象类。 当您看到“有”关系时，创建成员变量。 当您看到“依赖于外部提供者”时，请实现（而不是继承）接口。

面试问题：接口和抽象类有什么区别？ 您如何决定何时使用什么？ 我大多得到以下一个或全部答案： 答案1：你不能创建抽象类和接口的对象。

ZK（这是我名字的缩写）：你不能创建其中任何一个的对象。 所以这没有区别。 这是接口和抽象类之间的相似之处。 反问：为什么不能创建抽象类或接口的对象？

答案 2：抽象类可以有一个函数体作为部分/默认实现。

ZK：反问：所以如果我将其更改为纯抽象类，将所有虚函数标记为抽象，并且不为任何虚函数提供默认实现。 这会使抽象类和接口相同吗？ 之后它们可以互换使用吗？

答案 3：接口允许多重继承，而抽象类则不允许。

ZK：反问：你真的继承了接口吗？ 或者您只是实现一个接口并从抽象类继承？ 实现和继承有什么区别？ 这些反问问题让候选人感到困惑，让大多数人摸不着头脑，或者直接转向下一个问题。 这让我认为人们需要有关面向对象编程的这些基本构建块的帮助。 原始问题和所有反问题的答案可以在英语和 UML 中找到。 您必须至少了解以下内容才能更好地理解这两个结构。

普通名词：普通名词是同一类或同类事物的“共同”名称。 例如水果、动物、城市、汽车等。

专有名词：专有名词是物体、地点或事物的名称。 苹果、卡特彼勒、纽约、本田雅阁等。

汽车是一个普通名词。 本田雅阁是一个专有名词，并且可能是一个复合专有名词，一个使用两个名词组成的专有名词。

来到 UML 部分。 您应该熟悉以下关系：

• Is A
• Has A
• Uses

让我们考虑以下两个句子。 - 本田雅阁是汽车吗？ - 本田雅阁有车吗？

哪一个听起来正确？ 简单的英语和理解能力。 本田雅阁和汽车公司有着“Is A”的关系。 本田雅阁里面没有汽车。 这是辆车。 本田雅阁“有一个”音乐播放器。

当两个实体共享“Is A”关系时，它是继承的更好候选者。 Has a 关系是创建成员变量的更好候选者。 建立后，我们的代码如下所示：

abstract class Car
{
   string color;
   int speed;
}
class HondaAccord : Car
{
   MusicPlayer musicPlayer;
}

现在本田不生产音乐播放器。 或者至少这不是他们的主要业务。

于是他们联系其他公司并签订了合同。 如果您在这里接收电源并在这两条线上接收输出信号，那么这些扬声器就会正常播放。

这使得音乐播放器成为界面的完美候选者。 只要连接工作正常，您并不关心谁为其提供支持。

您可以将 LG 的 MusicPlayer 替换为 Sony 或其他方式。 这不会改变本田雅阁的任何事情。

为什么不能创建抽象类的对象？

因为你不能走进陈列室并说给我一辆车。 您必须提供一个专有名词。 什么车？ 应该是本田雅阁。 那时销售代理可以为您提供一些东西。

为什么不能创建接口的对象？ 因为你不能走进陈列室并说给我一份音乐播放器合同。 这不会有帮助。 消费者和提供商之间的接口只是为了促进达成协议。 您将如何处理协议副本？ 它不会播放音乐。

为什么接口允许多重继承？

接口不是继承的。 接口已实现。 界面是与外部世界交互的候选者。 本田雅阁有一个加油接口。 它具有用于给轮胎充气的接口。 以及用于给足球充气的同一软管。 因此，新代码将如下所示：

abstract class Car
{
    string color;
    int speed;
}
class HondaAccord : Car, IInflateAir, IRefueling
{
    MusicPlayer musicPlayer;
}

英文将如下所示：“本田雅阁是一款支持轮胎充气和加油的汽车”。

Answer 18

由 Jeffrey Richter 通过 C# 从 CLR 复制...

我经常听到这样的问题：“我应该设计基本类型还是接口？” 答案并不总是明确的。

以下是一些可能对您有所帮助的准则：

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

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

■■ 一致的实现无论接口契约的文档记录得多么好，它
每个人都 100% 正确执行合同的可能性很小。 事实上，COM
就遇到了这个问题，这就是为什么某些 COM 对象只能在以下情况下正常工作的原因：
微软
Word 或 Windows Internet Explorer。 通过提供一个具有良好性能的基本类型
默认实现，您首先使用有效且经过良好测试的类型； 那么你可以
修改需要修改的部分。

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

Answer 19

接口定义一个服务或一组服务的契约。 它们以水平方式提供多态性，两个完全不相关的类可以实现相同的接口，但可以互换地用作它们实现的接口类型的参数，因为这两个类都承诺满足接口定义的服务集。 接口不提供实现细节。

抽象类定义其子类的基本结构，以及可选的部分实现。 抽象类以垂直但有方向的方式提供多态性，因为任何继承抽象类的类都可以被视为该抽象类的实例，但反之则不然。 抽象类通常可以包含实现细节，但不能自行实例化 - 只有它们的子类可以“更新”。

请注意，C# 也允许接口继承。

Answer 20

接口是强制执行特定行为的轻量级方法。 这是一种思考方式。

Answer 21

大多数答案都集中在抽象类和接口之间的技术差异，但由于从技术上讲，接口基本上是一种抽象类（没有任何数据或实现），我认为概念< /strong> 差异要有趣得多，这可能就是面试官所追求的。

接口是一个协议。 它指定：“这就是我们彼此交谈的方式”。 它不能有任何实现，因为它不应该有任何实现。 这是一份合同。 它就像 C 中的 .h 头文件。

抽象类是一个不完整的实现。 类可以实现也可以不实现接口，并且抽象类不必完全实现它。 没有任何实现的抽象类有点无用，但完全合法。

基本上任何类，无论是否抽象，都是关于它是什么的，而接口则是关于你如何使用它的。 例如：Animal可能是一个实现一些基本代谢功能的抽象类，并指定呼吸和运动的抽象方法而不给出实现，因为它不知道是否应该通过鳃或肺呼吸，并且无论它飞、游泳、走还是爬。 另一方面，Mount 可能是一个接口，它指定您可以骑乘动物，而无需知道它是什么类型的动物（或者它是否是动物！）。

事实上，在幕后，接口基本上是一个只有抽象方法的抽象类，这一点并不重要。 从概念上讲，它们扮演着完全不同的角色。

Answer 22

由于您可能已经从专家那里获得了理论知识，因此我不会在这里花太多文字重复所有这些内容，而是让我用一个简单的示例来解释我们可以使用/不能使用 Interface 和 抽象类。

假设您正在设计一个应用程序来列出汽车的所有功能。 在各个方面，您都需要共同的继承，因为数字燃油表、空调、座椅调节等一些属性对于所有汽车来说都是通用的。 同样，我们只需要继承某些类，因为制动系统（ABS、EBD）等某些属性仅适用于某些汽车。

下面的类作为所有汽车的基类：

public class Cars
{
    public string DigitalFuelMeter()
    {
        return "I have DigitalFuelMeter";
    }

    public string AirCondition()
    {
        return "I have AC";
    }

    public string SeatAdjust()
    {
        return "I can Adjust seat";
    }
}

假设我们为每辆车都有一个单独的类。

public class Alto : Cars
{
    // Have all the features of Car class    
}

public class Verna : Cars
{
    // Have all the features of Car class + Car need to inherit ABS as the Braking technology feature which is not in Cars        
}

public class Cruze : Cars
{
    // Have all the features of Car class + Car need to inherit EBD as the Braking technology feature which is not in Cars        
}

考虑我们需要一种继承 Verna 和 Cruze 汽车（不适用于 Alto）制动技术的方法。 虽然两者都采用制动技术，但“技术”是不同的。 因此，我们创建一个抽象类，其中的方法将被声明为 Abstract，并且应该在其子类中实现。

public abstract class Brake
{
    public abstract string GetBrakeTechnology();
}

现在我们尝试继承这个抽象类，并在Verna和Cruze中实现制动系统的类型：

public class Verna : Cars,Brake
{
    public override string GetBrakeTechnology()
    {
        return "I use ABS system for braking";
    }       
}

public class Cruze : Cars,Brake
{
    public override string GetBrakeTechnology()
    {
       return "I use EBD system for braking";
    }         
}

看到上面两个类中的问题了吗？ 它们继承自 C#.Net 不允许的多个类，即使该方法是在子类中实现的。 这时候就需要Interface了。

interface IBrakeTechnology
{
    string GetBrakeTechnology();
}

实现如下：

public class Verna : Cars, IBrakeTechnology
{
    public string GetBrakeTechnology()
    {
        return "I use ABS system for braking";
    }
}

public class Cruze : Cars, IBrakeTechnology
{
   public string GetBrakeTechnology()
   {
       return "I use EBD system for braking";
   }        
}

现在Verna和Cruze可以借助Interface实现自己的制动技术的多重继承。

Answer 23

1）接口可以看成是一个纯抽象类，是一样的，但尽管如此，实现接口和继承抽象类还是不一样的。 当您从这个纯抽象类继承时，您正在定义一个层次结构 -> 继承，如果你实现了你不是的接口，你可以实现任意多个接口，但你只能继承一个类。

2) 您可以在接口中定义属性，因此实现该接口的类必须具有该属性。

例如：

  public interface IVariable
  {
      string name {get; set;}
  }

实现该接口的类必须具有这样的属性。

Answer 24

虽然这个问题已经很老了，但我想添加另一点支持接口：

接口可以使用任何依赖注入工具来注入，而抽象类注入很少得到支持。

Answer 25

来自我的另一个答案，主要涉及何时使用其中一种：

根据我的经验，界面是最好的
当您有多个课程时使用
每个人都需要响应相同的
方法或方法，以便它们可以
与其他代码互换使用
这将针对那些写
类的公共接口。 最好的
使用接口是当
协议很重要，但
底层逻辑可能不同
每堂课。 如果你不这样的话
重复逻辑，考虑抽象
类或标准类继承
相反。

Answer 26

接口类型与抽象基类

改编自Pro C# 5.0 和 .NET 4.5 Framework< /a> 书。

接口类型可能看起来与抽象基类非常相似。 记起
当一个类被标记为抽象时，它可以定义任意数量的抽象成员来提供
所有派生类型的多态接口。 然而，即使一个类确实定义了一组抽象
成员，也可以自由定义任意数量的构造函数、字段数据、非抽象成员（带有
实施）等。 另一方面，接口仅包含抽象成员定义。
由抽象父类建立的多态接口有一个主要限制
因为只有派生类型支持抽象父类定义的成员。 然而，在较大的
在软件系统中，开发没有共同父级的多个类层次结构是很常见的
超越 System.Object。 鉴于抽象基类中的抽象成员仅适用于派生类
类型，我们没有办法在不同的层次结构中配置类型来支持相同的多态
界面。 举例来说，假设您定义了以下抽象类：

public abstract class CloneableType
{
// Only derived types can support this
// "polymorphic interface." Classes in other
// hierarchies have no access to this abstract
// member.
   public abstract object Clone();
}

根据此定义，只有扩展 CloneableType 的成员才能支持 Clone()
方法。 如果您创建一组不扩展此基类的新类，则无法获得此
多态接口。 另外，您可能还记得 C# 不支持类的多重继承。
因此，如果您想创建一个既是 Car 又是 CloneableType 的 MiniVan，您将无法这样做：

// Nope! Multiple inheritance is not possible in C#
// for classes.
public class MiniVan : Car, CloneableType
{
}

正如您所猜测的，接口类型可以解决问题。 定义好接口后，可以
可以由任何类或结构、任何层次结构、任何命名空间或任何程序集中实现
（用任何 .NET 编程语言编写）。 正如您所看到的，接口是高度多态的。
考虑名为 ICloneable 的标准 .NET 接口，它在 System 命名空间中定义。 这
接口定义了一个名为 Clone() 的方法：

public interface ICloneable
{
object Clone();
}

Answer 27

第二个问题的答案：interface中定义的public变量默认是static final，而public变量在< code>abstract 类是一个实例变量。

Answer 28

从编码的角度来看，

如果抽象类仅具有抽象方法，则接口可以替换抽象类。 否则，将抽象类更改为接口意味着您将失去继承提供的代码可重用性。

从设计角度

来看，如果它是“是”关系并且您需要部分或全部功能，请将其保留为抽象类。 如果它是“应该做”的关系，则将其保留为接口。

决定您需要什么：只是策略执行，还是代码可重用性和策略。

Answer 29

当然，理解 OOP 中接口和抽象类的行为（以及语言如何处理它们）很重要，但我认为理解每个术语的确切含义也很重要。 您能想象 if 命令并不完全按照该术语的含义工作吗？ 另外，实际上有些语言正在减少甚至更多地减少接口和抽象之间的差异......如果有一天这两个术语的操作几乎相同，至少你可以定义自己应该在哪里（以及为什么）它们中的任何一个用于。

如果您阅读一些词典和其他字体，您可能会发现同一术语有不同的含义，但有一些共同的定义。 我认为我在这个网站中找到的这两个含义真的非常好而且合适。

界面：

使独立且有时不兼容的元素能够有效协调的事物或情况。

抽象的：

某种东西集中了任何更广泛或更普遍的事物或几个事物的本质品质； 本质。

示例：

您买了一辆汽车，它需要燃料。

您的汽车模型是 XYZ，属于 ABC 流派，因此它是一辆具体汽车，是汽车的特定实例。 汽车不是真实的物体。 事实上，它是创建特定对象的一组抽象标准（质量）。 简而言之，Car 是一个抽象类，它是“集中了更广泛或更一般事物的基本品质的东西”。

应使用唯一符合汽车手册规格的燃油来填充汽车油箱。 实际上，没有什么限制您添加任何燃油，但发动机只有使用指定的燃油才能正常工作，因此最好遵循其要求。 这些要求表明，与其他同类型ABC汽车一样，它接受一套标准燃料。

在面向对象的视图中，类型 ABC 的燃料不应声明为类，因为没有针对特定类型汽车的具体燃料。 尽管您的汽车可以接受抽象类 Fuel 或 VehillaryFuel，但您必须记住，只有部分现有的车辆燃料符合规范，即那些实现汽车手册中要求的燃料。 简而言之，他们应该实现接口 ABCGenreFuel，该“...使单独且有时不兼容的元素能够有效地协调”。

附录

此外，我认为您应该记住术语“类”的含义，即（来自前面提到的同一站点）：

类：

由于共同的属性、特征、品质或特征而被视为形成一个群体的许多人或事物； 种类；

这样，类（或抽象类）不应仅表示公共属性（如接口），而应表示某种具有公共属性的组。 接口不需要代表一种。 它必须代表共同属性。 这样，我认为类和抽象类可以用来表示不应该经常改变其方面的事物，比如人类和哺乳动物，因为它代表了某些种类。 物种不应该那么频繁地改变自己。

Answer 30

其他几个区别：

抽象类可以有静态方法、属性、字段等，而运算符、接口则不能。
强制转换运算符允许与抽象类进行强制转换，但不允许与接口强制转换。

因此，即使抽象类从未实现（通过其静态成员），您也可以单独使用抽象类，并且您不能以任何方式单独使用接口。