接口vs抽象类（通用OO）

#1 楼

虽然您的问题表明它是针对“通用OO”的，但实际上它似乎主要集中于.NET对这些术语的使用。

在.NET（与Java类似）中：


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

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

确实，有一个称为非虚拟接口（NVI）的C ++习惯用法，其中公共方法是“虚化”为私有虚拟方法的非虚拟方法：


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

#2 楼

打个比方：当我在空军时，我参加了飞行员培训，成为了美国空军的飞行员。那时我没有资格飞行任何东西，不得不参加飞机型号培训。合格后，我将成为飞行员（抽象班）和C-141飞行员（混凝土班）。在我的一项任务中，我被赋予了额外的职责：安全员。现在，我仍然是飞行员和C-141飞行员，但是我也履行了安全主任的职责（可以说我实施了ISafetyOfficer）。不需要飞行员担任安全官员，其他人也可以做到。

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


飞行员：抽象类
C-141飞行员：具体类
ISafety Officer：界面

添加了说明：这只是一个类比来帮助解释该概念，而不是编码建议。请参阅下面的各种评论，讨论很有趣。

#3 楼

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

当派生类共享抽象类的核心属性和行为时，将使用抽象类继承。

另一方面，当类共享外围行为（不一定定义派生类的行为）时，使用接口继承。 >例如汽车和卡车具有许多汽车抽象类的核心属性和行为，但是它们还共享一些外围行为，例如“生成排气”，甚至是非汽车类（例如Drillers或PowerGenerators）也具有这种特性，并且不一定定义汽车或卡车，因此汽车，卡车，司钻和PowerGenerator都可以共享同一接口IExhaust。

#4 楼

简短说明：抽象类用于对外观相似的类的类层次结构进行建模（例如Animal可以是抽象类，而Human，Lion，Tiger可以是具体派生类）

AND

接口用于2个相似/不相似类之间的通信，这些类不关心实现Interface的类的类型（例如，Height可以是interface属性，可以由Human，Building，Tree来实现。可以吃东西，可以游泳，可以死，也可以做其他任何事情。.这仅是一件需要高度的事情（在课堂上实施）。

#5 楼

还有其他一些区别-

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

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

可以在v2 +中修改抽象基类而不会破坏API。接口的更改是重大更改。

[C＃/。NET特定]接口与抽象基类不同，可以将其应用于值类型（结构）。结构不能从抽象基类继承。这允许将行为合同/使用准则应用于值类型。

#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;
}

关于继承。如上所述，我们使用它们将对象分类为更简单的Base形式及其子类。
Abstract类
Abstract类是不完整的对象。为了进一步理解它，让我们再次考虑车辆的类比。
可以驾驶车辆。对？但是，不同的车辆以不同的方式行驶。例如，您不能像驾驶自行车一样驾驶汽车。
那么如何表示车辆的驱动功能呢？很难检查它是什么类型的车辆并以其自身的功能驾驶它。您必须在添加新型车辆时一次又一次地更改Driver类。
这里是抽象类和方法的角色。您可以将drive方法定义为抽象的，以告诉每个继承的子代都必须实现此功能。
因此，如果您修改车辆类...

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

自行车和汽车还必须指定如何开车。否则，代码将无法编译，并且会引发错误。
简而言之。抽象类是部分不完整的类，具有一些不完整的功能，继承子代必须指定它们自己的功能。
Interfaces
接口完全不完整。它们没有任何属性。它们只是表明继承的孩子有能力做某事...
假设您有不同类型的手机。它们每个都有不同的方式来执行不同的功能。例如：打电话给一个人。手机的制造商指定如何进行。手机可以在此处拨打号码-即可以拨打。让我们将其表示为接口。

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接口，而这只是该函数所关心的。
开发人员通常使用接口来确保对象之间的互操作性（可互换使用），只要它们共享一个公共功能（就像您可能会更改一样）即可。只需拨打一个电话就可以拨打座机或手机）。简而言之，接口是抽象类的简单得多的版本，没有任何属性。
此外，请注意，您可以实现（继承）任意数量的接口，但只能扩展（继承）单个父类。
更多信息
抽象类与接口

#7 楼

如果您认为java是OOP语言来回答此问题，则Java 8版本会导致上述答案中的某些内容过时。现在，java接口可以具有带有具体实现的默认方法。

Oracle网站提供了interface和abstract类之间的主要区别。

如果要共享代码，请考虑使用抽象类：


在几个密切相关的类之间。
您希望扩展抽象类的类具有许多公共方法或字段，或者需要除public之外的访问修饰符（例如protected和private）。
您想声明为non -静态或非最终字段。

考虑使用接口，如果：


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

简单来说，我想使用

接口：通过多个不相关的对象实现合同

抽象类：实现多个相关对象之间的行为相同或不同

看看代码示例，以清楚的方式理解事物：如何解释接口和抽象类之间的区别？

#8 楼

面试官正在吠叫一棵奇怪的树。对于C＃和Java之类的语言，有区别，但是在诸如C ++之类的其他语言中则没有区别。 OO理论并没有区别这两种语言，只是语言的语法。

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

在C＃或Java中，没有任何实现的抽象类与接口的区别仅在于用于继承该接口的语法，而且您只能从一个继承。

#9 楼

通过实现接口，您将实现组合（“具有”关系）而不是继承（“具有”关系）。这是记住诸如设计模式之类的重要原则，在这种情况下，您需要使用接口来实现行为的组成而不是继承。

#10 楼

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

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

2-接口是一种合同，是一组或多组功能代表的完整的业务功能。这就是为什么它被实现而不是被继承。业务对象（是否属于层次结构）可以具有任意数量的完整业务功能。它与抽象类无关，通常意味着继承。例如，人类可以运行，大象可以运行，鸟类可以运行，依此类推，所有这些不同层次的对象都将实现RUN接口或EAT或SPEAK接口。不要进行实现，因为您可能会实现每个实现这些接口的每种类型都有抽象类。任何层次结构的对象都可以具有与其层次结构无关的功能（接口）。

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

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

我相信，两位面试官都期望这两者之间存在一种直接的区别，当您失败时，他们试图通过将ONE实施为另一种来促使您实现这种区别。


如果只有抽象方法的抽象类怎么办？

#11 楼

我将解释接口和抽象类的深度详细信息。如果您了解接口和抽象类的概述，那么您何时应该使用接口以及何时应该使用抽象类的问题就浮现在脑海中。
所以请检查以下解释接口和抽象类的说明。



什么时候应该使用接口？

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


当我们应该使用Abstract类时？

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

接口

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

Abstract

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

接口

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

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

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

接口方法
我们也不能将接口声明为私有，受保护，最终，静态，同步，本地.....

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

我们很高兴地与public，private最终静态...一起使用。这意味着抽象中没有任何限制。

接口

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

可变修饰符也不适用于接口，因为接口变量默认情况下为公共静态最终变量最后一个变量，一旦将值分配给变量，并且在将变量声明为接口后就必须分配变量，就不能更改值。

volatile变量会不断变化，因此它是opp。最终是因为我们不在接口中使用volatile变量的原因。
Abstract

Abstract变量无需声明公共静态final。


希望这篇文章对您有用。

评论

---

我不同意这一点：抽象类必须至少具有一个抽象方法。只要实现它，就有可能没有Abstract方法的Abstract类。参考：抽象类是被声明为抽象的类-它可能包含也可能不包含抽象方法。参考资料：docs.oracle.com/javase/tutorial/java/IandI/abstract.html

–德夫纳
2014年12月2日，7：10

---

您在谈论技术细节和实施，不是在一般OOP方面回答问题

– Billal Begueradj
18年8月18日在7:14

---

#12 楼

对于.Net，

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

编辑：另一方面，我什至不使用短语“子类”（或“继承性”短语）来描述“定义为实现”接口的类。对我而言，接口是对合同的定义，如果已经定义了一个类来“实现”该接口，则该类必须遵循该合同。它不会继承任何东西...您必须自己显式添加所有内容。

#13 楼

接口：如果要对可能相互关联或不相互关联的组件隐含规则，则应使用




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

缺点：


必须实现所有定义的契约
不能有变量或委托
一旦定义就不能不破坏所有的类而不能更改

Abstract Class：应该用于希望彼此相关的组件具有某些基本或默认行为或实现的地方

优点：


比接口更快捷
有实现的灵活性（可以完全或部分实现）
可以轻松更改而不会破坏派生类

缺点：


实例化的
不支持多重继承

#14 楼

我认为他们不喜欢您的回答，因为您提供了技术差异而不是设计差异。这个问题对我来说就像一个巨魔问题。实际上，接口和抽象类的性质完全不同，因此您无法真正进行比较。我将向您介绍接口的作用和抽象类的作用。

interface：用于确保协定并在类之间建立低耦合，以便具有更可维护，可扩展和可测试的应用程序。抽象类：仅用于分解具有相同责任的类之间的某些代码。请注意，这是在OOP中多继承是一件坏事的主要原因，因为类不应承担许多责任（请改用合成）。

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

#15 楼

接口：

我们不实现（或定义）方法，而是在派生类中实现。
我们不在接口中声明成员变量。
接口表示HAS-A关系。这意味着它们是对象的掩码。


抽象类：

我们可以在抽象类中声明和定义方法。
我们隐藏了以下对象的构造函数它。这意味着没有直接从中创建对象。
抽象类可以容纳成员变量。
派生类继承给抽象类，这意味着派生类中的对象没有被屏蔽，它继承了抽象类。在这种情况下的关系是IS-A。



这是我的看法。

#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?" 

文档清楚地指出，如果抽象类仅包含抽象方法声明，则应将其声明为接口。

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

变量默认情况下，接口中的public静态和最终。如果抽象类中的所有变量都是公共的，该问题可能会被框起来？好吧，它们仍然可以是非静态的和非最终的，与接口中的变量不同。

最后我要在上面提到的那些上再加一点-抽象类仍然是类，并且属于单个继承树，而接口可以存在于多个继承中。

#17 楼

Jeffrey Richter通过C＃从CLR复制了它。

我经常听到一个问题，“我应该设计基本类型还是接口？”答案并不总是很明确。

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

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

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

■■一致的实现无论接口合同的文档记载如何，
每个人都不太可能实现正确签约100％。实际上，COM
遇到了这个问题，这就是为什么某些COM对象只能在
Microsoft
Word或Windows Internet Explorer中正常工作的原因。通过为基本类型提供良好的默认实现，您可以开始使用有效且经过良好测试的类型。然后您可以
修改需要修改的零件。

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

#18 楼

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

抽象类为其子类定义基本结构，并可以选择部分实现。抽象类以垂直但有方向的方式提供多态性，因为任何继承了抽象类的类都可以被视为该抽象类的实例，但不能反过来。抽象类可以并且经常确实包含实现细节，但是不能单独实例化-只有它们的子类可以被“更新”。

C＃也允许接口继承。 />

#19 楼

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

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

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

基本上，任何类（无论是否抽象）都与它的本质有关，而接口与它的使用方式有关。例如：Animal可能是一个抽象类，它实现一些基本的代谢功能，并在没有给出实现的情况下指定用于呼吸和运动的抽象方法，因为它不知道它应该通过g还是肺呼吸，以及它是否飞行，游泳，行走或爬行。另一方面，Mount可能是一个界面，它指定您可以骑乘动物而无需知道它是哪种动物（或根本不是动物！）。

事实在幕后，接口基本上是只具有抽象方法的抽象类，没关系。从概念上讲，它们扮演着完全不同的角色。

#20 楼

您可能已经从专家那里获得了理论知识，所以我在这里不再赘述，而是让我用一个简单的示例来说明，其中我们可以使用/不能使用Interface和Abstract class。

考虑您正在设计一个应用程序，以列出汽车的所有功能。在各个方面，您都需要共同的继承，因为所有汽车都拥有一些属性，例如DigitalFuelMeter，空调，座椅调节等。同样，我们仅需要对某些类进行继承，因为诸如制动系统（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 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借助自己的制动技术实现多重继承。

#21 楼

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

#22 楼

这些答案太长了。


接口用于定义行为。
抽象类用于定义事物本身，包括其行为。这就是为什么我们有时会创建一个带有继承接口的一些额外属性的抽象类的原因。
这也解释了为什么Java只支持类的单一继承，而对接口没有任何限制。因为一个具体的对象不能是不同的事物，但是它可以具有不同的行为。

#23 楼

1）接口可以看作是一个纯抽象类，它是相同的，但是尽管如此，实现一个接口并从抽象类继承还是不一样。从这个纯抽象类继承时，您将定义一个层次结构->继承，如果您实现的不是接口，则可以实现任意数量的接口，但只能从一个类继承。

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

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

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

#24 楼

尽管这个问题已经很老了，但我想补充一点，以便支持接口：

可以使用任何依赖注入工具来注入接口，其中很少有人支持Abstract类注入。

#25 楼

从我的另一个答案中，主要涉及何时使用一个与另一个：


根据我的经验，当您有多个类时，最好使用接口

每个都需要响应相同的一个或多个方法，以便它们可以与其他代码互换使用，而这些代码将针对这些类的公共接口编写。接口的最佳用法是在
协议很重要但每个类的基础逻辑可能不同的情况下。如果您否则会
复制逻辑，请考虑使用抽象类
或标准类继承
。

#26 楼

接口类型与抽象基类

来自Pro C＃5.0和.NET 4.5 Framework书。

接口类型似乎与抽象基类非常相似。回想一下
，当一个类被标记为抽象时，它可以定义任意数量的抽象成员，以为所有派生类型提供
多态接口。但是，即使一个类确实定义了一组抽象
成员，也可以自由定义任意数量的构造函数，字段数据，非抽象成员（具有
实现），等等。另一方面，接口仅包含抽象成员定义。
由抽象父类建立的多态接口受到一个主要限制
，因为只有派生类型支持抽象父定义的成员。但是，在较大的
软件系统中，开发在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＃不支持类的多重继承。
因此，如果您要创建的是-a Car和is-a CloneableType的MiniVan，则无法这样做：

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

您可能会猜到，接口类型可以解决。定义接口后，可以
由任何类或结构，任何层次结构，任何名称空间或任何程序集中的接口实现
（以任何.NET编程语言编写）。如您所见，接口是高度多态的。
考虑在System名称空间中定义的标准.NET接口ICloneable。该
接口定义了一个名为Clone（）的方法：

public interface ICloneable
{
object Clone();
}

#27 楼

回答第二个问题：public中定义的interface变量默认是static final，而public类中的abstract变量是实例变量。

#28 楼

当然，了解OOP中的接口和抽象类的行为（以及语言如何处理）很重要，但是我认为了解每个术语的确切含义也很重要。您能想象if命令不能完全按照术语的含义工作吗？同样，实际上，某些语言正在减少甚至更大程度地减少界面和抽象之间的差异……如果有一天偶然，两个术语的操作几乎完全相同，至少您可以定义自己应该在哪里（以及为什么）

如果您通读一些词典和其他字体，可能会发现同一术语具有不同的含义，但具有一些常见的定义。我认为我在本站点中发现的这两种含义确实非常非常好并且很合适。

接口：


一种事物或情况，可以分开，有时不兼容元素可以有效地进行协调。


摘要：


某种东西本身就集中了更广泛或更普遍的事物或某些事物的本质素质东西本质。


示例：

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



您的汽车模型是XYZ，属于流派ABC，因此它是混凝土车，是汽车的特定实例。汽车不是真正的物体。实际上，它是创建特定对象的一组抽象标准（质量）。简而言之，Car是一个抽象类，它是“某种东西，它本身集中了任何更广泛或更普遍的东西的本质素质”。

只能使用符合汽车手册规格的燃料来填充汽车油箱。实际上，没有任何限制可以放任何燃料，但发动机只能使用指定的燃料才能正常工作，因此最好遵循其要求。要求说，它像其他同类ABC的汽车一样接受标准燃料。

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

附录

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

类：



由于共同的属性，特征，品质或特质而被视为一个团体的许多人或事物； kind;


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

#29 楼

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

从Design Perspective

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

确定您需要的内容：仅执行策略，或代码可重用性和策略。

#30 楼

其他一些差异：

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

几乎可以使用抽象类，即使它从未实现（通过其静态成员），也不能单独使用接口方式。