在面向对象的编程语言中，抽象类和接口是并存的两个概念，它们之间有很大的相似性，然而也存在一些区别。简单的概括，从语法上来讲，抽象类是可以实例化的，但是接口不存在实例化的问题。从设计的角度来讲，体现出设计者对于相关问题域的诠释。有的面向对象的编程语言，只支持单继承，但是支持多接口。通过接口的方式可以达到或者实现类似于C++中多继承的机制。
对于只支持单继承的编程语言，通过抽象类和接口的使用，更能够体现设计者对问题域的诠释。用AlarmDoor（报警门）这一类作例子，将问题域解释为“门，带有报警功能”和“报警器，是个门”在设计的过程中是会有差别的，这种差别可以通过抽象类和接口的应用体现出来。
作为“门，带有报警功能”，一般的做法是将门设计为抽象类，而将报警器设计为接口。门的抽象类中提供开和关两个抽象方法，报警器接口提供报警方法。有人也许会问，为什么不在门这个类中直接声明报警方法，而要费尽周折用到接口。
现在我们来明确一下这个问题。如果我的门，只有开关两个方法，那么我既可以声明为抽象类，也可以声明为接口，我们知道这两者是有很大的相似性的，问题在于，如果现在我有一个门，它除了具有开关的功能之外，还具有报警的功能。这时，我是要修改门这个类（或者接口），显然这是不符合面向对象的一个核心原则ISP（Interface Segregation Priciple，接口分离原则），把门固有的行为方法和另外一个概念“报警器”的行为混在一起了。这样我们才用到了接口分离，或者通过一个抽象类，或者通过一个接口，我们现在的问题在于是选择抽象类还是接口。
那么，为什么要将门设计为抽象类，而将报警器设计为接口呢？
再来看一下我们的问题域，也就是我们是怎么理解这个问题的。这里我们将其解释为“门，带有报警功能”。门具有其固有的方法，比如开、关，我们的“报警门”完全可以继承自这样的“门”类，因为我们至少可以继承自某一个类，很自然地，对于单继承，“报警器”类就只能作为接口出现了。当然，我们也完全可以将“门”设计为接口，“报警门”既实现“门”的接口，也实现“报警器”的接口。然而再一想，我们通常是将“狗”类继承自“动物”还是使用接口呢？
再来看我们对这个问题域的另外一种诠释：报警器，是个门。根据前面的介绍，我们会很自然地想到，我们可以采用继承自“报警器”同时实现“门”接口这样的设计方式。
至于最终我们采用抽象类还是接口，取决于我们对问题域的认识，也就是具体问题具体对待。很多人都习惯性地认为二者没有多大的区别，哪个好用就用哪个自然也无可厚非。就像有人习惯用结构体，有人习惯用类，我们可能会考虑到结构体作为值类型效率会高一些，类则可以增强扩展性，各有利弊，各有千秋。关键在于我们认识到它们到底是什么，就像英文单词“how”，一见就知道是“怎么”的意思，我们也就没有必要深究为什么三个字母拼起来会表示这样的意思了。。。