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

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

接口:

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

抽象类:

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

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

另请参阅:

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


当前回答

当然,理解OOP中接口和抽象类的行为(以及语言如何处理它们)很重要,但我认为理解每个术语的确切含义也很重要。你能想象if命令不能完全按照这个词的意思工作吗?此外,实际上,一些语言正在减少,甚至更多地减少界面和抽象之间的差异。。。如果碰巧有一天这两个术语几乎相同,那么至少你可以定义它们中的任何一个应该用于何处(以及为什么)。

如果你阅读一些字典和其他字体,你可能会发现同一个词有不同的含义,但有一些共同的定义。我认为我在这个网站上找到的这两个意思真的非常好,非常适合。

接口:

使分离的、有时不相容的元素能够有效协调的事物或环境。

摘要:

集中于自身的东西,集中于任何更广泛或更普遍的事物或若干事物的本质;本质

例子:

你买了一辆车,它需要燃料。

你的汽车模型是XYZ,属于ABC类型,所以它是一辆具体的汽车,一辆汽车的具体实例。汽车不是实物。事实上,它是一组抽象的标准(质量)来创建特定的对象。简而言之,Car是一个抽象的类,它是“集中于自身的任何更广泛或更一般的东西的本质”。

应使用符合汽车手册规格的唯一燃油来加注汽车油箱。实际上,没有什么可以限制您添加任何燃油,但发动机只能在指定的燃油下正常工作,因此最好遵循其要求。该要求表示,与其他同类ABC汽车一样,该公司接受一套标准燃油。

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

补遗

此外,我认为你应该记住class这个词的含义,它是(来自前面提到的同一个网站):

类别:

一群人或事物由于共同的属性、特征、品质或特点而被视为组成一个群体;友善的

这样,类(或抽象类)不应只表示公共属性(如接口),而是表示具有公共属性的某种组。接口不需要表示一种。它必须表示公共属性。通过这种方式,我认为类和抽象类可以用来表示不应该经常改变其方面的事物,比如人类是哺乳动物,因为它代表了某些种类。种类不应该经常改变自己。

其他回答

还有一些其他的区别-

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

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

抽象基类可以在v2+中修改,而不破坏API。对接口的更改正在破坏更改。

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

由于您可能已经从专家那里获得了理论知识,所以我不会花太多的时间来重复这里的所有内容,而是让我用一个简单的例子来解释,我们可以使用/不能使用Interface和Abstract类。

假设您正在设计一个应用程序来列出汽车的所有功能。在不同的方面,您需要共同继承,因为一些财产,如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的帮助下通过自己的制动技术实现多重继承。

遗产考虑一辆汽车和一辆公共汽车。它们是两种不同的车辆。但是,它们仍然有一些共同的财产,比如它们有方向盘、制动器、齿轮、发动机等。因此,使用继承概念,这可以表示如下。。。

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表单及其子表单,如上文所示。

抽象类

抽象类是不完整的对象。为了进一步理解它,让我们再次考虑车辆类比。可以驾驶车辆。正确的但不同的车辆以不同的方式行驶。。。例如,你不能像驾驶自行车一样驾驶汽车。那么如何表示车辆的驱动功能呢?很难检查它是什么类型的车辆,并使用它自己的功能驾驶它;在添加新类型的车辆时,您必须反复更改驾驶员类别。这里是抽象类和方法的作用。您可以将驱动方法定义为抽象的,以告知每个继承的子级都必须实现此函数。所以如果你修改了车辆等级。。。

//......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的函数的编写者无需担心其财产。它有触摸屏或拨号盘吗?是固定固定电话还是移动电话。你只需要知道它是否可以拨号;它是否继承(或实现)可拨号接口。

更重要的是,如果有一天你将可拨号电话换成另一个

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

您可以确定代码仍然完美运行,因为使用可拨号接口的功能不(也不可能)依赖于可拨号接口中指定的细节以外的细节。它们都实现了可拨号接口,这是函数唯一关心的事情。

开发人员通常使用接口来确保对象之间的互操作性(可互换使用),只要它们共享一个共同的功能(就像您可以换成座机或移动电话,只要您只需要拨打一个号码)。简而言之,接口是抽象类的一个简单得多的版本,没有任何财产。此外,请注意,您可以实现(继承)任意多的接口,但只能扩展(继承)单个父类。

更多信息抽象类与接口

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

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

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

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

当你被问到差异时,这实际上是概念上的差异,而不是特定语言实现中的差异,除非被明确问到。

我相信,两位面试官都希望这两者之间有一条直线的直接区别,当你失败时,他们试图通过将“一个作为另一个”来驱使你实现这一区别

如果你有一个只有抽象方法的抽象类呢?

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

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

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

基本上,任何类,无论抽象与否,都是关于它是什么,而接口则是关于你如何使用它。例如:Animal可能是一个抽象类,它实现了一些基本的代谢功能,并在没有给出实现的情况下指定了呼吸和运动的抽象方法,因为它不知道它应该通过鳃还是肺呼吸,行走或爬行。另一方面,Mount可能是一个接口,它指定你可以骑动物,而不知道它是什么动物(或者它是否是动物!)。

在幕后,接口基本上是一个只有抽象方法的抽象类,这一点无关紧要。从概念上讲,他们扮演着完全不同的角色。