简单英语什么是AOP、依赖注入和控制反转

Question

我试图理解 AOP、依赖注入和控制反转 SPRING 相关概念，但我很难理解它。

谁能用简单的英语解释一下？

Answer 1

我理解您的困惑，我花了一些时间才理解这些概念是如何相互关联的。所以这是我对这一切的（某种程度上个人的）解释：

1。控制反转

控制反转是一个相当通用的设计原则，指的是解耦实际执行时的行为规范。例如，

myDependency.doThis();

与

myDependency.onEventX += doThis();

后者相比，没有直接调用，更加灵活。就其一般形式而言，控制反转与观察者模式、事件或回调相关。

2.依赖倒置

依赖倒置是另一个设计原则。粗略地说，它表示高层抽象不应该直接依赖于低层抽象；这确实会导致设计中，如果没有较低级别的抽象，就无法重用较高级别的抽象。

 class MyHighLevelClass {
     MyLowLevelClass dep = new MyLowLeverClass();
 }

 class App {
     void main() {  new HighLevelClass().doStuff(); }
 }

这里，如果不访问 MyLowLevelClass，MyHighLevelClass 就无法编译。为了打破这种耦合，我们需要用接口抽象低级类，并删除直接实例化。

class MyLowLevelClass implements MyUsefulAbstraction { ... }

class MyHighLevelClass {

    MyUsefulAbstraction dep;

    MyHighLevelClass( MyUsefulAbstraction dep ) {
        this.dep = dep;
    }
}

class App {
     void main() {  new HighLevelClass( new LowLevelClass() ).doStuff(); }
 }

请注意，您不需要任何特殊的东西（例如容器）来强制依赖倒置，这是一个原则。值得一读的是 Uncle Bob 所著的依赖倒置原理。

3.依赖注入

现在是依赖注入。对我来说，依赖注入 = IoC + 依赖倒置：

1. 依赖项是外部提供的，因此我们强制执行依赖倒置原则，
2. 容器设置依赖项（而不是我们），因此我们谈论控制反转

在上面我提供的示例中，如果使用容器来实例化对象并在构造函数中自动注入依赖项，则可以完成依赖项注入（我们经常谈到 DI 容器）：

 class App {
     void main() {  DI.getHighLevelObject().doStuff(); }
 }

请注意，有各种 注入形式。另请注意，从这个角度来看， setter 注入 可以被视为回调的一种形式 - DI 容器创建对象然后回调 setter。控制流程实际上被颠倒了。

4. AOP

严格来说，AOP 和前面3点关系不大。 关于 AOP 的开创性论文非常通用且现实将各种源代码编织在一起（可能用不同的语言表达）以生成可用软件的想法。

我不会对 AOP 进行更多展开。这里重要的是，依赖注入和 AOP 确实有效地协同工作，因为它使编织变得非常容易。如果使用 IoC 容器和依赖项注入来抽象对象的实例化，则可以轻松地使用 IoC 容器在注入依赖项之前编织各个方面。否则，这将需要特殊的编译或特殊的类加载器。

希望这有帮助。

Answer 2

依赖注入在 如何向 5 岁的孩子解释依赖注入？：

当你去拿东西的时候
自己的冰箱，你可以
造成问题。你可能会离开
门打开，你可能会得到一些东西
妈妈或爸爸不想让你这么做
有。您甚至可能正在寻找
一些我们甚至没有的东西
已过期。

你应该做的是陈述一个
需要，“我需要喝点东西
午餐，”然后我们会确保您
当你坐下来时有东西
吃。

AOP - 面向方面的编程 - 基本上意味着您编写的源代码是根据位于其他地方的规则用其他代码修改的。这意味着您可以说“作为每个方法的第一行，我希望在中心位置有一个 'log.debug("entering method()")' 以及您编译的每个方法然后，该规则将包含该行。“方面”是以其他方式查看代码的名称，而不是简单地从第一个源代码行到最后一个代码行，这

基本上意味着您没有控制的核心代码段 。一切（就像 main() 中的一个巨大的开关），但有很多代码“不知何故”被调用。这个主题在维基百科上讨论：http://en.wikipedia.org/wiki/Inversion_of_control

Answer 3

这三个概念都是不同的，但它们都能很好地协同工作，因此 Spring 应用程序经常同时使用它们。我给你举个例子。

假设我们有一个可以执行许多不同操作的 Web 应用程序。我们可以通过多种方式构建这个应用程序，但一种方法是创建一个类来负责完成这些事情。我们需要从某个地方调用并创建这些类。一种选择是有一个大的主类，它创建每个服务之一，打开一个套接字，并在这些服务进入时将调用传递给它们。不幸的是，我们已经为自己创建了一个上帝类，它有方法太多的逻辑并且对我们程序中的所有内容如何工作了解太多。如果我们改变程序的任何内容，我们可能需要修改这个类。

而且，测试也很困难。如果任何类直接实例化和调用其他类，我们就无法单独测试它。单元测试变得越来越难编写。

解决这个问题的一种方法是使用控制反转。我们说“好吧，这些是服务类。谁创建了它们？不是我。”通常，每个服务都定义一个接口，例如 LoginService 或 BillingService。该接口可能有多个实现，但您的应用程序并不关心。它只知道它可以请求某种类型的服务或具有特定名称的服务，并且它会得到一些不错的回报。

依赖注入允许我们将所有的小片段连接在一起。类具有可访问的字段、构造函数参数或 setter 方法，它们是对其需要访问的其他组件的引用。这使得单元测试变得更加容易。您可以创建被测试的对象，向其抛出模拟或存根依赖项，然后测试该对象是否在隔离中正确运行。

现在，我们真正的应用程序是一个复杂的杂乱片段，所有这些片段都需要连接在一起。有很多方法可以实现这一点，包括允许应用程序进行猜测（“这个类需要一个 UserService，而我负责的另一个类则实现了 UserService”）或者仔细解释它们如何在 XML 中连接在一起或Java。 Spring 的核心是一个负责将这些类连接在一起的服务。

现在我们进入 AOP。假设我们拥有所有这些以复杂方式相互连接的类。我们可能希望以非常通用的方式描述一些跨领域的问题。例如，您可能希望在调用任何服务时启动数据库事务，并在服务不引发异常时提交该事务。事实证明，Spring 处于执行此类任务的独特位置。 Spring 可以动态创建代理类来实现您的类所需的任何接口，并且它可以将您的类包装在其代理中。现在，IoC 和依赖注入当然不是面向方面编程所必需的，但它是实现它的一种极其方便的方法。

Answer 4

中很好地解释了依赖注入和控制反转之间的区别

http://martinfowler.com/articles/dipInTheWild .html

（“你的意思是依赖倒置，对吧？”部分）

摘要：

DI 是关于一个对象如何获取依赖关系。当依赖
外部提供，则系统使用DI。

IoC 是关于谁发起调用的。如果您的代码发起调用，
如果容器/系统/库回调到代码，则不是 IoC
你提供的，是 IoC。

Answer 5

让我告诉你一些关于AOP的知识，希望它能让你更容易理解。
AOP 的基本原则是找到返回的常见任务/方面
代码中的很多地方并不属于代码的具体业务。例如
写入以登录任何函数的每个入口，或者在创建对象时对其进行包装，或者在调用特定函数时向管理员发送电子邮件。
因此，我们不是由程序员来处理这些非业务方面，而是从他们那里获取并
我们在幕后管理这些方面。
AOP 的所有基本功能都在 1 条腿上......

Answer 6

Spring in Action 的简单比较：

而 DI 可以帮助您解耦应用程序
对象之间相互独立，AOP 可以帮助您将横切关注点与对象之间解耦
它们影响的对象。