akn*_*non 9 java interface dependency-inversion
我无法弄清楚依赖性反转原理(SOLID原则之一)与通用"代码到接口"或分离接口模式之间的区别.他们都提倡创建一个抽象层来分离较低级别和较高级别的模块.
DI原则设想创建在更高层和更低层模块之间交互的接口,但也坚持接口必须是更高层包的一部分.
为什么这应该是更高层次而不是更低层次的一部分？它是暴露其行为的较低级别,所以解耦接口不应该是较低级别的一部分吗？如果有多个更高级别的模块取决于相同的较低级别怎么办？
或者,
为什么不制作一个单独的包来放置所有接口,然后可以被更高级别和更低级别使用？(这是分离接口模式设想的.)
我的困境是,我无法弄清楚它们的相对用途和好处.
请不要引用Derek Greer或Robert Martin的文章.我读过这些文章,但仍然存在混淆.
依赖倒置是一个概念，它是依赖注入框架（如 Spring、Guice 等）的构建块。它的意思是组件不应该查找其依赖项，而应该从外部注入其依赖项。组件的依赖项可以是接口或另一个类。当依赖是一个接口时，组件就可以灵活地与各种实现一起工作。
让我们举个例子：假设有人正在编写一个需要进行一些服务调用的组件。如果组件开发人员认为服务调用必须始终使用 HTTP 进行，那么她将使 HTTP 客户端成为依赖项。现在，这限制了组件实用程序只能调用基于 HTTP 的服务。然而，同一开发人员可以创建一个接口（例如 GenericExternalServiceInvoker），并实现两个实现 - 一个使用 HTTP，另一个使用 ActiveMQ 等某种排队系统。接口的使用使组件开发人员能够创建具有更广泛用途的组件。
在上面的例子中，我们假设 DI 已经就位。因为依赖项是从外部注入的。组件开发人员可以做出另一种设计选择，并且可以在代码中实例化 HTTP 客户端，从而使组件的用户在需要时很难更改其行为以使用 HTTP 之外的其他内容。
因此，总而言之，应该使用 DI，以便组件不以硬连线方式依赖于其依赖项。通过使组件的依赖成为一个接口，组件中内置了进一步的灵活性。第二个原则，“代码到接口”，是开发人员选择接口作为依赖项而不是具体类的指导因素。