需要澄清：抽象类优先于接口。原因：他们将合同与实施分开

Question

使用抽象（Visual Basic中的MustInherit）类而不是接口来将合同与实现分离。

以上内容来自Microsoft的"Type design guideline"。我对此有点困惑。我一直认为接口将合同与实现分离。上述指南到底意味着什么？

谢谢

Answer 1

抽象类和接口都可以“将契约与实现分离”。在抽象类中，方法可以声明为抽象，而不是实现，就像使用接口时一样。对于这样的方法，dervived类必须提供带有实现的Override方法，就像使用接口时一样。

抽象类和接口之间的区别在于抽象类可以包含一些具有实现的成员，然后在所有派生类之间共享，并且它可以包含私有/受保护字段（“state”） ，界面显然不能。

Answer 2

我认为这就是它所说的。如果你想将契约与实现分离，他们建议你使用抽象类而不是接口。

我理解他们所做的建议是，当您需要与自定义值类型相关的多态性时，或者如果您想要多继承，或者因为类型将具有大量实现者时，您使用接口。例如，IDisposable通常与多个其他接口一起继承，而IDisposable由很多不同的类实现，因此它们作为接口的规则是有意义的。

如果你的合同不会与其他合同一起实施，并且它将由8个或10个不同的成员实施，那么抽象类通过我读这个的方式是有意义的。

Answer 3

接口确实将合同与实现分离。您引用的类型设计指南并不意味着将接口与实现分离的界面很差 - 这意味着接口具有抽象类没有的额外限制，因此如果您有选择，这些指导方针建议您倾斜在想要定义没有实现的契约而不是自动定义接口时定义抽象类。

在设计应用程序中使用的合同时，这可能是公平的建议。但是，如果合同将在您的应用程序之外使用，例如通过COM或.NET远程处理的进程外调用，或跨不同语言（在.NET之外），则接口具有明显的优势。当您需要绝对隔离和实现的独立性时，接口优于抽象类。为了方便和长期灵活应用（当不需要绝对隔离接口时），指南建议您可以使用抽象类而不是接口。

指南的措辞部分反映了人们倾向于过度使用接口，这可能导致不必要的混乱和冗余的实现代码。