什么是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();}类应用{void main() { new HighLevelClass().doStuff();}}

这里，MyHighLevelClass 不能在没有访问MyLowLevelClass 的情况下编译.为了打破这种耦合，我们需要抽象具有接口的低级类，并删除直接实例化.

class MyLowLevelClass 实现了 MyUsefulAbstraction { ... }类 MyHighLevelClass {MyUsefulAbstraction dep;MyHighLevelClass(MyUsefulAbstraction dep) {this.dep = dep;}}类应用{void main() { new HighLevelClass( new LowLevelClass() ).doStuff();}}

注意，你不需要像容器这样的特殊东西来强制依赖倒置，这是一个原则.一个很好的读物是The Dependency Unreferrer">The Dependency Unreferrer">The Dependency Inverse/p>

3.依赖注入

现在是依赖注入.对我来说依赖注入 = IoC + 依赖倒置:

1. 依赖是外部提供的，所以我们强制执行依赖倒置原则
2. 容器设置依赖项(不是我们)所以我们说控制反转

在我上面提供的示例中，如果使用容器实例化对象并在构造函数中自动注入依赖项(我们经常说DI容器)，则可以完成依赖注入:>

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

请注意，有多种注射形式.还要注意，在这个角度下，setter injection 可以看作是一种回调形式——DI 容器创建对象，然后回调 setter.控制流程被有效地反转.

4.AOP

严格来说，AOP与前3点关系不大.关于 AOP 的开创性论文 非常通用且存在将各种来源(可能用不同的语言表达)编织在一起以生成可运行的软件的想法.

我不会对 AOP 进行更多的扩展.这里重要的是，依赖注入和 AOP 确实可以很好地协同工作，因为它使编织非常容易.如果使用 IoC 容器和依赖项注入来抽象对象的实例化，则可以轻松地使用 IoC 容器在注入依赖项之前编织方面.否则，这将需要特殊的编译或特殊的 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屋！