我理解你的困惑,我花了一些时间来理解这些概念是如何联系在一起的。所以这里是我的(不知何故个人的)所有这一切的解释:
控制反转
Inversion of control是一种设计原理,而非泛型,指的是行为的规范与实际执行时的行为的去耦。比较例,
myDependency.doThis();
与
myDependency.onEventX += doThis();
在后者中,没有更灵活的直接调用。在其一般形式中,控制的反转涉及观察者模式,事件或回调。
2.依赖性反演
依赖性反转是另一种设计原则。粗略地说,它表示更高级的抽象不应该直接依赖于低级抽象;这实际上导致了在没有低级抽象的情况下不能重用更高级抽象的设计。
class MyHighLevelClass {
MyLowLevelClass dep = new MyLowLeverClass();
}
class App {
void main() { new HighLevelClass().doStuff(); }
}
这里,MyHighLevelClass不能编译,而无法访问MyLowLevelClass。要打破这种耦合,我们需要使用接口抽象低级类,并删除直接实例化。
class MyLowLevelClass implements MyUsefulAbstraction { ... }
class MyHighLevelClass {
MyUsefulAbstraction dep;
MyHighLevelClass( MyUsefulAbstraction dep ) {
this.dep = dep;
}
}
class App {
void main() { new HighLevelClass( new LowLevelClass() ).doStuff(); }
}
注意,你不需要任何特殊的像容器来强制执行依赖性反转,这是一个原则。好的阅读是鲍勃叔叔The Dependency Inversion Principle。
依赖注入
现在依赖注入。对我来说依赖注入= IoC依赖反转:
>依赖性在外部提供,因此我们实施依赖性反转原理
>容器设置依赖(而不是我们),所以我们说控制的反转
在上面提供的示例中,如果使用容器实例化对象并自动注入构造函数中的依赖关系(我们经常说DI容器),则可以执行依赖注入:
class App {
void main() { DI.getHighLevelObject().doStuff(); }
}
注意,有各种form of injections.注意,在这个透视下,setter injection可以看作一种回调的形式 – DI容器创建对象,然后回调setter。控制的流动被有效地反转。
4.AOP
严格地说,AOP与前面3点没什么关系。 seminal paper on AOP是非常通用的,并提出了编织各种源(可能表示为不同的语言),以产生一个工作软件的想法。
我不会扩大AOP。这里重要的是,依赖注入和AOP有效地在一起很好地发挥作用,因为它使得编织非常容易。如果使用IoC容器和依赖注入来抽象出对象的实例化,那么IoC容器可以轻松地用于在注入依赖项之前编织这些方面。否则这将需要特殊的编译或特殊的ClassLoader。
希望这可以帮助。