Spring 为什么接口而不是抽象类？

Question

有时，我们以某种自动方式使用 Spring。今天我在思考和搜索以下内容。

为什么我们习惯在 Spring 中这样做？ @Autowired IAnimal 动物；

为什么我们通常不做这样的事情？ @Autowired 动物；

Animal 是一个抽象类，在我们的 beans.xml 中，或者使用带有限定符的@Autowired，我们可以指定我们想要的实现。狗，猫等。

我知道我错了，但我想解释一下抽象类方法而不是接口方法的缺点。

现在，如果我们想注入一些 ORM 实现，Ibatis 或 Hibernate，使用接口注入更有意义，因为两个提供者不共享抽象类，但它们共享相同的接口。但是还有其他例子吗？

提前致谢！

Answer 1

接口的主要优点是多重继承。Java 不允许您扩展多个类，这是有合理原因的。一些语言允许这样做（例如 C++ 和其他语言）并且它有用是有原因的，但 Java 不允许。但是，您可以实现多个接口。关于什么是接口和什么是抽象类，还有一个更微妙的问题。如果你有class MyClass extends MyAbstractClass，你实际上是在说“的所有实例MyClass都是”的实例MyAbstractClass。这适用于应用于 OOP 的最常见隐喻。例如，所有的狗实际上都是动物。然而，接口只是定义了一些行为。在许多编程上下文中，通过事物的功能来定义事物比它们是什么更有意义。例如，狗是可吠叫的、可奔跑的、可行走的、可喂食的，等等……在这里您定义它可以做什么。对于您的 Spring 示例，您可能并不关心您正在使用的对象实际上是一个 Animal，您可能只关心它可以做 Animals可以做的所有事情。这是首选接口的主要原因。

Answer 2

在早期的 Spring 版本中，声明一个接口可能是强制性的，以使 bean 可以使用一些需要通过接口生成代理类的功能。最近的 Spring 版本不再有此限制。所以现在，在 Spring 中（和没有 Spring 一样）一个共享的良好实践是让一个 bean 类仅在有意义的情况下实现一个接口：KISS（保持简单和愚蠢）原则。抽象是有代价的，我们只有在有充分理由的情况下才愿意接受它。

Answer 3

这真的取决于你的项目。IAnimal如果您可能有此类接口的多个实现并且您将决定在打包过程中使用哪一个，则您希望使用接口 ( )。例如，假设根据IAnimal您是在 Windows 还是 Linux 下实现需要不同，在打包过程中您可能希望准备两个不同版本的应用程序（一个用于 Windows 和一个用于 Linux）并且每个包将仅包含适用于该平台的代码。在这种情况下，您将在一个包中包含 Windows 的实现，而在另一种情况下，您将包含 Linux 的实现。另一种常见情况是团队作为“黑匣子”工作，一个团队需要另一个团队的依赖。在那种情况下，团队之间达成的所有协议都是实施的“契约”（即：接口）。您的团队将能够针对您构建的“模拟”实现进行工作，而另一个团队开发最终将发布的实现。否则，一般的建议是“保持简单”，只有在证明需要时才添加接口。不这样做会导致代码过多，这只会让每个人的生活都变得困难。