oop - 何时使用接口(interface)或抽象类？何时使用两者？

Question

虽然某些指导方针规定，当您想要为继承不明确的类( IDomesticated )定义契约(Contract)时应该使用接口(interface)，而当类是另一个类的扩展时( Cat : Mammal ， Snake : Reptile )，您应该使用接口(interface)，在某些情况下(在我看来)这些指南进入了灰色地带。

例如，假设我的实现是 Cat : Pet . Pet是一个抽象类。是否应该扩展到 Cat : Mammal, IDomesticated在哪里 Mammal是一个抽象类，IDomesticated是接口(interface)吗？还是我与 KISS 冲突？/YAGNI原则(即使我不确定将来是否会有 Wolf 类，它不能从 Pet 继承)？

远离隐喻Cat s 和 Pet s，假设我有一些类代表传入数据的来源。他们都需要以某种方式实现相同的基础。我可以在摘要中实现一些通用代码 Source类并从中继承。我也可以做一个 ISource接口(interface)(对我来说感觉更“正确”)并在每个类中重新实现通用代码(不太直观)。最后，我可以通过创建抽象类和接口(interface)来“吃蛋糕”。什么是最好的？

这两种情况提出了只使用抽象类、只使用接口(interface)以及同时使用抽象类和接口(interface)的问题。这些都是有效的选择，还是有“规则”来说明何时应该使用一个而不是另一个？

我想通过“同时使用抽象类和接口(interface)”来澄清这一点，其中包括它们本质上代表相同事物的情况(Source 和 ISource 都具有相同的成员)，但是该类添加了通用功能而接口(interface)指定合约。

另外值得注意的是，这个问题主要针对不支持多重继承的语言(例如 .NET 和 Java)。

Answer 1

作为第一条经验法则，我更喜欢抽象类而不是接口(interface)，based on the .NET Design Guidelines .推理的适用范围比 .NET 更广泛，但在 Framework Design Guidelines 书中有更好的解释。 .

偏爱抽象基类的主要原因是版本控制，因为您总是可以在不破坏现有客户端的情况下向抽象基类添加新的虚拟成员。使用接口(interface)是不可能的。

在某些情况下，接口(interface)仍然是正确的选择(尤其是当您不关心版本控制时)，但了解其优点和缺点使您能够做出正确的决定。

因此，作为我继续之前的部分答案:只有当您决定首先针对接口(interface)进行编码时，同时拥有接口(interface)和基类才有意义。如果您允许接口(interface)，则必须仅针对该接口(interface)进行编码，否则您将违反 Liskov 替换原则。换句话说，即使你提供了一个实现接口(interface)的基类，你也不能让你的代码使用那个基类。

如果您决定针对基类进行编码，那么拥有接口(interface)是没有意义的。

如果您决定针对接口(interface)进行编码，则具有提供默认功能的基类是可选的。这不是必需的，但可能会加快实现者的速度，因此您可以提供一个作为礼貌。

一个浮现在脑海中的例子是 ASP.NET MVC。请求管道在 IController 上工作，但有一个 Controller 基类，您通常使用它来实现行为。

最终答案:如果使用抽象基类，请仅使用它。如果使用接口(interface)，基类是对实现者的一种可选礼遇。

更新:我不再喜欢抽象类而不是接口(interface)，而且我已经很久没有了；相反，我更喜欢组合而不是继承，使用 SOLID 作为指导。

(虽然我可以直接编辑上面的文字，但它会从根本上改变帖子的性质，而且由于一些人发现它的值(value)足以支持它，我宁愿保留原文，而是添加这个注意。帖子的后半部分仍然有意义，所以删除它也很遗憾。)