什么是简单英语中的AOP，依赖注入和控制反转 [英] What is AOP, Dependency Injection and Inversion Of Control in Simple English

问题描述

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

任何人都可以用简单的英文解释这个问题吗？

解决方案

你的困惑，花了我一些时间来了解这些概念是如何联系在一起的。所以这里是我（不知何故的个人）解释所有这些：

1。

反转控制是一种非常通用的设计原则，指的是行为规范与实际执行时的解耦。比较例如，

  myDependency.doThis（）; 
  

与

  myDependency.onEventX + = doThis（）; 
  

在后者中，没有直接调用更灵活。在其一般形式中，控制的反转涉及观察者模式，事件或回调。

2。依赖性反转

依赖反转是另一种设计原则。粗略地说，高层抽象不应该直接取决于较低层次的抽象;这样做的结果确实在没有较低级别抽象的情况下不能重复使用高级抽象的设计。

  class MyHighLevelClass {
 MyLowLevelClass dep = new MyLowLeverClass（）; 
} 
 
 class App {
 void main（）{new HighLevelClass（）。doStuff（）; } 
} 
  

这里， MyHighLevelClass 无法访问 MyLowLevelClass 无法编译。要打破这种耦合，我们需要使用一个接口来抽象这个低级别的类，并删除直接的实例化。

  class MyLowLevelClass实现MyUsefulAbstraction {...} 
 
 class MyHighLevelClass {
 
 MyUsefulAbstraction dep; 
 
 MyHighLevelClass（MyUsefulAbstraction dep）{
 this.dep = dep; 
} 
} 
 
类App {
 void main（）{new HighLevelClass（new LowLevelClass（））.doStuff（）; } 
} 
  

请注意，您不需要任何特殊的容器来强制依赖反转，这是一个原则。好的阅读是Bob叔叔依赖性反转原则。 / p>

3。依赖注入

现在是依赖注入。对我来说，依赖注入= IoC +依赖关系反转：

1. 依赖关系在外部提供我们强制执行依赖关系反转原理


2. 容器设置依赖关系（而不是我们），所以我们谈论控制的反转

在上面提供的示例中，如果容器用于实例化对象并自动在构造函数中注入依赖关系，我们可以完成依赖注入（我们经常讨论DI容器） ：

  class App {
 void main（）{DI.getHighLevelObject（）。doStuff（）; } 
} 
  

请注意，有各种注入形式。还要注意，在这个角度来看，设定者注入可以看作是一种回调形式 - DI容器创建对象然后调用setter。控制流程有效地反转。

4。 AOP

严格来说，AOP与上述3点几乎没有关系。 关于AOP的开创性论文非常通用和现代将各种资源编织在一起（可能用不同语言表达）的想法来制作工作软件。

我不会在AOP上扩展更多。这里重要的是依赖注入和AOP的确有效地发挥了很好的作用，因为它使编织非常简单。如果使用IoC容器和依赖注入来抽象化对象的实例化，那么在注入依赖项之前，I​​oC容器可以轻松地用于编织这些方面。否则将需要一个特殊的编译或特殊的 ClassLoader 。

希望这有帮助。

I have tried to understand AOP, Dependency Injection and Inversion of Control SPRING related concepts but I am having hard time understanding it.

Can anyone explain this in simple English ?

解决方案

I understand your confusion and it took me some time to understand how these concepts were related together. So here is my (somehow personal) explanation of all this:

1. Inversion of Control

Inversion of control is a design principle rather generic that refers to the decoupling of the specification of a behavior from when it is actually executed. Compare for instance,

myDependency.doThis();

with

myDependency.onEventX += doThis();

In the latter, there is no direct invocation which is more flexible. In its general form, inversion of control relates to the observer pattern, events, or callbacks.

2. Dependency inversion

Dependency inversion is another design principle. Roughly speaking, it says that higher-level abstraction should not depend directly on lower-level abstractions; this results indeed in a design where higher-level abstraction can not be reused without the lower-level abstractions.

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

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

Here, MyHighLevelClass can not compile without access to MyLowLevelClass. To break this coupling, we need to abstract the low level class with an interface, and remove the direct instantiation.

class MyLowLevelClass implements MyUsefulAbstraction { ... }

class MyHighLevelClass {

    MyUsefulAbstraction dep;

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

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

Note that you don't need anything special like a container to enforce dependency inversion, which is a principle. A good reading is The Dependency Inversion Principle by Uncle Bob.

3. Dependency injection

Now comes dependency injection. To me dependency injection = IoC + dependency inversion:

1. dependencies are provided externally so we enforce the dependency inversion principle
2. the container sets the dependencies (not us) so we speak of inversion of control

In the example I provided above, dependency injection can be done if a container is used to instantiate objects and automatically inject the dependency in the constructor (we speak then frequently of DI container):

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

Note that there are various form of injections. Note also that under this perspective, setter injection can be seen as a form of callback -- the DI container creates the object then calls back the setter. The flow of control is effectively inverted.

4. AOP

Strictly speaking, AOP has little to do with the 3 previous points. The seminal paper on AOP is very generic and present the idea of weaving various sources together (possibly expressed with different languages) to produce a working software.

I won't expand more on AOP. What is important here, is that dependency injection and AOP do effectively plays nicely together because it makes the weaving very easy. If an IoC container and dependency injection is used to abstract away the instantiation of objects, the IoC container can easily be used to weave the aspects before injecting the dependencies. This would otherwise requires a special compilation or a special ClassLoader.

Hope this helps.

这篇关于什么是简单英语中的AOP，依赖注入和控制反转的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！