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

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);
}
.....

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

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

更多信息抽象类与接口

接口：-==合约。无论哪个类实现它都必须遵循接口的所有规范。

一个实时的例子是任何ISO标记的产品。ISO给出了一套规则/规范，说明产品应该如何构建以及它必须具备的最小功能集。

这只是产品必须具备的财产的子集。SO只有在产品满足其标准时才会签署产品。

现在看看这个代码

public interface IClock{       //defines a minimum set of specification which a clock should have

    public abstract Date getTime();
    public abstract int getDate();
}
public class Fasttrack: Clock {
    // Must have getTime() and getTime() as it implements IClock
    // It also can have other set of feature like 
    public void startBackgroundLight() {
        // watch with internal light in it.
    }
    .... //Fastrack can support other feature as well
    ....
    ....
}

在这里，Fastrack被称为手表，因为它具有手表必须具备的所有功能（最小功能集）。

原因和时间摘要：

来自MSDN：

抽象类的目的是提供多个派生类可以共享的基类的公共定义。

例如，类库可以定义一个抽象类，该抽象类用作其许多函数的参数，并要求使用该库的程序员通过创建派生类来提供自己的类实现。抽象只是指如果你不能定义它，就将它完全声明为抽象。实现类将完成这个实现。

例如：假设我声明一个类配方是抽象的，但我不知道该是哪个配方然后我将推广这个类来定义任何菜谱的通用定义。菜谱的植入将取决于菜品的实现。

抽象类既可以由抽象方法组成，也可以由非抽象方法组成。因此，您可以注意到接口中的差异。因此，实现类不一定必须具有每个方法。您只需要重写抽象方法。

简单来说，如果您想要紧密耦合，请使用接口o/w，以防失去耦合抽象类

还有一些其他的区别-

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

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

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

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

面试官们正在寻找一棵奇怪的树。对于像C#和Java这样的语言，这是有区别的，但在其他语言中，像C++没有区别。OO理论并没有区分这两者，仅仅是语言的语法。

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

在C#或Java中，没有任何实现的抽象类与接口的区别仅在于用于从其继承的语法以及只能从其中继承的事实。

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

接口：我们不实现（或定义）方法，而是在派生类中实现。我们不在接口中声明成员变量。接口表示HAS-A关系。这意味着它们是对象的遮罩。抽象类：我们可以在抽象类中声明和定义方法。我们隐藏了它的构造函数。这意味着没有直接从它创建对象。抽象类可以保存成员变量。派生类继承到抽象类，这意味着派生类中的对象不被屏蔽，它继承到抽象类别。这种情况下的关系是is-A。

这是我的看法。