简而言之，差异如下：

接口和抽象类之间的语法差异：

抽象类的方法和成员可以具有任何可见性。接口的所有方法都必须是公共的//Java 9不再适用抽象类的具体子类必须定义所有抽象方法。抽象子类可以具有抽象方法。扩展另一个接口的接口不需要为从父接口继承的方法提供默认实现。子类只能扩展单个类。一个接口可以扩展多个接口。一个类可以实现多个接口。子类可以定义具有相同或更少限制性可见性的抽象方法，而实现接口的类必须将所有接口方法定义为公共的。抽象类可以有构造函数，但不能有接口。来自Java9的接口具有私有静态方法。

现在在界面中：

公共静态-支持公共摘要-支持公共默认值-支持私有静态-支持私有抽象-编译错误私有默认值-编译错误私有-支持

我想再加一个有意义的区别。例如，您有一个包含数千行代码的框架。现在，如果您想使用方法enhanceUI（）在整个代码中添加新特性，那么最好在抽象类中添加该方法，而不是在接口中添加。因为，如果在接口中添加此方法，那么应该在所有已实现的类中实现它，但如果在抽象类中添加方法则不是这样。

实际上并不是最初问题的答案，但一旦你找到了它们之间的区别的答案，你就会进入何时使用每一个困境：何时使用接口或抽象类？何时同时使用两者？

我对OOP的了解有限，但将接口视为语法中形容词的等价物对我来说一直有效（如果这个方法是假的，请纠正我！）。例如，接口名称类似于可以赋予类的属性或功能，并且类可以具有许多属性或功能：ISerializable、ICountable、IList、ICacheable、IHappy。。。

接口与抽象类的比较是错误的。应该有另外两个比较：1）接口与类，2）抽象与最终类。

接口与类

接口是两个对象之间的契约。例如，我是一名邮递员，而你是一个要递送的包裹。我希望你知道你的送货地址。当有人给我一个包裹时，它必须知道它的送货地址：

interface Package {
  String address();
}

类是一组遵守契约的对象。例如，我是“箱子”小组的一名箱子，我遵守邮递员要求的合同。同时，我遵守其他合同：

class Box implements Package, Property {
  @Override
  String address() {
    return "5th Street, New York, NY";
  }
  @Override
  Human owner() {
    // this method is part of another contract
  }
}

摘要与最终

抽象类是一组不完整的对象。它们不能使用，因为它们缺少一些部件。例如，我是一个抽象的GPS感知框-我知道如何检查我在地图上的位置：

abstract class GpsBox implements Package {
  @Override
  public abstract String address();
  protected Coordinates whereAmI() {
    // connect to GPS and return my current position
  }
}

这个类如果被另一个类继承/扩展，可能非常有用。但就其本身而言，它是无用的，因为它不能有对象。抽象类可以是最终类的构建元素。

Final类是一组完整的对象，可以使用，但不能修改。他们确切地知道如何工作和做什么。例如，我是一个盒子，它总是在构建过程中到达指定的地址：

final class DirectBox implements Package {
  private final String to;
  public DirectBox(String addr) {
    this.to = addr;
  }
  @Override
  public String address() {
    return this.to;
  }
}

在大多数语言中，如Java或C++，可能只有一个类，既不是抽象类也不是最终类。这样的类可以继承并实例化。不过，我认为这并不严格符合面向对象的范例。

同样，将接口与抽象类进行比较是不正确的。

总结起来最简单的方法是：

完全抽象，除了默认和静态方法；虽然它有默认和静态方法的定义（方法签名+实现），但它只有其他方法的声明（方法签名）。受比类更宽松的规则约束（类可以实现多个接口，接口可以从多个接口继承）。所有变量都是隐式常量，无论是否指定为公共静态final。所有成员都是隐式公共的，无论是否指定为公共成员。通常用于保证实现类将具有指定的特性和/或与实现相同接口的任何其他类兼容。

同时，抽象类是：

从完全抽象到完全实现，具有一个或多个抽象方法的倾向。可以包含声明和定义，声明标记为抽象。一个完整的类，并且受制于管理其他类的规则（只能从一个类继承），条件是它不能实例化（因为不能保证它完全实现）。可以具有非常量成员变量。可以实现成员访问控制，将成员限制为受保护、私有或私有包（未指定）。通常用于提供可由多个子类共享的尽可能多的实现，或者提供程序员能够提供的尽可能的实现。

或者，如果我们想将其归结为一句话：接口是实现类所拥有的，而抽象类是子类所拥有。

我迟到10年了，但我想尝试任何方法。几天前写了一篇同样的帖子。我想把它张贴在这里。

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

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

ZK（这是我的首字母缩写）：你不能创建任何一个对象。所以这并不是什么区别。这是接口和抽象类之间的相似之处。柜台问题：为什么不能创建抽象类或接口的对象？

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

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

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

ZK：反问：你真的从接口继承吗？还是只实现一个接口，从抽象类继承？实现和继承之间有什么区别？这些反问题会让考生们措手不及，让大多数人挠头，或者直接进入下一个问题。这让我觉得人们需要帮助来构建面向对象编程的基本构件。原始问题和所有反问题的答案都可以在英语和UML中找到。为了更好地理解这两个结构，您必须至少了解以下内容。

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

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

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

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

是A有A使用

让我们考虑下面的两句话。-本田雅阁是一辆车？-本田雅阁有车吗？

哪一个听起来正确？简单的英语和理解能力。本田雅阁（HondaAccord）和汽车（Cars）有着“是A”的关系。本田雅阁（Honda accord）没有车，它“是”一辆车。本田雅阁“有一个”音乐播放器。

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

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

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

因此，他们联系其他公司并签订合同。如果你在这里接收到电源和这两条电线上的输出信号，它在这些扬声器上会播放得很好。

这使得Music Player成为界面的完美候选。你不在乎谁为它提供支持，只要连接正常即可。

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

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

因为你不能走进展厅说给我一辆车。你必须提供一个专有名词。什么车？可能是本田雅阁。这就是销售代理可以给你东西的时候。

为什么不能创建接口的对象？因为你不能走进展厅说给我一份音乐播放器的合同。这没用。接口位于消费者和提供者之间，只是为了促成协议。你将如何处理协议副本？它不会播放音乐。

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

接口未被继承。接口已实现。界面是与外部世界交互的候选界面。本田雅阁有一个加油接口。它有给轮胎充气的接口。和用来给足球充气的软管一样。因此，新代码如下所示：

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

英文的意思是“本田雅阁是一款支持轮胎充气和加油的汽车”。