Spring为什么用接口代替抽象类？

Question

有时，我们以某种自动方式使用Spring。 今天我正在思考和寻找追随者。

为什么我们在春季使用此功能？ @Autowired IAnimal动物；

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

Animal是一个抽象类，在我们的beans.xml中，或者通过将@Autowired与Qualifier配合使用，我们可以指定所需的实现，如Dog，Cat等。

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

现在，如果我们要注入一些ORM实现（Ibatis或Hibernate），则使用接口注入更有意义，因为两个提供程序都不共享抽象类，而是共享相同的Interface。但是还有其他示例吗？

提前致谢！

Answer 1

在早期的Spring版本中，必须声明接口才能使Bean使用某些需要通过接口生成代理类的功能。
最新的Spring版本没有此限制。 因此，现在，在Spring（与没有Spring一样）中，一个共同的良好实践是仅在有意义的情况下使Bean类实现接口：KISS（保持简单和愚蠢）原理。
抽象是有代价的，我们仅出于充分的理由才愿意接受。

Answer 2

接口的主要优点是多重继承。 Java不允许您扩展多个类，这是有道理的。 某些语言（例如C ++和其他语言）允许这样做，并且有一定的原因使它有用，但Java却没有。

但是，您可以实现多个接口。 关于接口真正是什么和抽象类是什么还有一个更微妙的问题。

如果您拥有class MyClass extends MyAbstractClass ，那么您实际上是在说“所有MyClass实例都是MyAbstractClass实例”。 这适用于应用于OOP的最常见的隐喻。 例如，所有的狗实际上都是动物。

但是，接口仅定义了一些行为。 在许多编程环境中，通过事物可以做 什么而不是事物来定义事物更有意义。 例如，狗是可吠叫，可奔跑，可步行，可喂食的……在这里，您定义它可以做什么。

在您的Spring示例中，您可能并不在乎所使用的对象实际上是动物，您可能只是在乎它可以完成动物可以做的所有事情 。 这就是为什么首选接口的主要原因。

Answer 3

这确实取决于您的项目。

如果您可能要使用一个接口（ IAnimal ）来实现该接口的多种实现，并且要决定在打包过程中使用哪个接口，则需要使用该接口。

例如，假设您是在Windows还是Linux下， IAnimal上的实现IAnimal需要不同，在打包过程中，您可能需要准备两种不同版本的应用程序（一个用于Windows，一个用于Linux），并且每个软件包都包含仅适用于该平台的代码。 在这种情况下，将在一个软件包中包含Windows的实现，而在另一个软件包中将包含Linux的实现。

另一种常见的情况是团队充当“黑匣子”，其中一个团队需要另一团队的依赖。 在这种情况下，团队之间达成的所有协议就是实施的“合同”（即：接口）。 您的团队将能够与您自己构建的“模拟”实现抗衡，而另一团队则开发最终将被发布的实现。

否则，一般建议是“保持简单”并仅在证明需要时添加接口。 不这样做将导致不必要的代码过多，这只会使每个人的生活变得困难。