控制反转（Inversion Of Controller）的一个著名的同义原则是由Robert C.Martin提出的依赖倒置原则（Dependency Inversion Principle），它的另一个昵称是好莱坞原则（Hollywood Principle）：不要找我们，让我们来找你。
依赖和耦合（Dependency and Coupling）
依赖：依赖描述了两个模型元素之间的关系，如果被依赖的模型元素发生变化就会影响到另一个模型元素。
耦合：如果改变程序的一个模块要求另一个模块同时发生变化，就认为这两个模块发生了耦合。
从上面的定义中可以看出，如果模块A调用模块B提供的方法，或者访问模块B中的某些数据成员（当然，在面向对象开发中一般不提倡这样做），我们就认为模块A依赖于模块B，模块A和模块B之间发生了耦合。
那么，依赖对于我们来说到底是好事还是坏事呢？
由于人类的理解力有限，大多数人难以理解和把握过于复杂的系统（大神或天才除外），因此，把软件系统划分为多个模块，可以有效控制模块的复杂度，使每个模块都易于理解和维护。但在这种情况下，模块之间就必须以某种方式交换信息，也就是说，必然要发生某种耦合关系。如果某个模块和其它模块没有任何关联（哪怕是潜在的或隐含的依赖关系），我们就几乎可以断定，该模块不属于此软件系统，应该从系统中剔除。如果所有模块之间都没有任何耦合关系，其必然导致一个结果：整个软件不过是多个互不相干的系统的简单堆积，对每个系统而言，所有功能还是要在一个模块中实现，相当于没有做任何模块的分解。
因此，模块之间必然会有这样或那样的依赖关系，永远不要幻想消除所有依赖，但是，过强的耦合关系（如，一个模块的变化，会造成一个或多个其他模块也同时发生变化的依赖关系），会对软件系统的质量造成很大的危害。特别是当需求发生变化时，代码的维护成本将非常高。多以，我们必须想尽办法来控制和消除不必要的耦合，特别是那些会导致其它模块发生不可控变化的依赖关系。
依赖倒置、控制反转、依赖注入等原则，就是人们在和依赖关系进行艰苦斗争的过程中不断产生和发展起来的。
接口和实现分离（Interface And Implement）
把接口和实现分开是人们试图控制依赖关系的第一个尝试。
Java语言提供了纯粹的接口类，这种接口类不包含任何实现代码，只是定义了要做什么功能，具体的实现代码写在实现该接口类的实现类中。
这样的做法可以很好地隔离两个模块。
依赖倒置（Dependency Inversion Principle）
依赖倒置原则是建立在抽象接口的基础上：
A：上层模块不应该依赖于下层模块，它们共同依赖于一个抽象。
B：抽象不能依赖于具象，而是具象依赖于抽象。
含义是，为了消除两个模块间的依赖关系，应该在两个模块之间定义一个抽象接口，上层模块调用抽象接口定义函数，下层模块实现该接口。
控制反转（Inversion Of Controller）
控制反转
依赖注入（Dependency Injection）
依赖注入