什么是控制反转
可能重复：
什么是控制反转？
我明白依赖注入（DI）是什么（我认为！）。 它基本上是对象可能具有的依赖关系的满足。 我尝试着将使用DI作为面向服务的代码编写，并将我的代码定义为使用其他服务。
但是，我现在想知道，当使用IoC时，我们正在颠倒控制权。 这是一个相当模糊的术语，它可能意味着一些事情。
但是，我认为这是创建对象（并因此满足使用DI的依赖关系）的责任，由IoC框架处理。
请求使用对象（即 - 服务）仍然是应用程序的责任，区别在于它不知道（或关心）如何创建它。 那么，为什么服务定位器只是在要求服务时才被视为反模式？
我有正确的吗？ 或者这是否意味着别的什么。 另外，我是否已将DI和IoC的职责正确分开？ 如果我有，那么没有DI框架，IoC框架就无法运行。 或者DI仅仅是IoC框架的一个特性？
依赖注入通常意味着将依赖对象作为参数传递给方法，而不是让方法创建依赖对象。 它在实践中意味着该方法不直接依赖于特定的实现; 任何满足要求的实现都可以作为参数传递。
控制反转简单地认识到依赖关系是相反的。 A不是通过创建，实现或直接调用A而依赖于B，而是将A作为参数接收，并且不再以任何方式对B负责。
将参数类型实现为接口简化了过程，并对其进行了概括，但并非绝对必要。
控制反转是一种普遍的模式。 依赖注入是该模式的一种用法。 有关更多信息，请参见Martin Fowler撰写的这篇文章，特别是标题为“控制反转”的部分。
很多人现在避免了DI的“控制反转”这个词，因为反转与人们在依赖注入变得普遍之前做事情的方式相比。 如果你现在习惯了依赖注入，或者是从一开始就有这种想法的人，那么试图弄清楚什么是反转就是令人困惑。
控制反转基本上意味着应用程序代码不关心它需要的部分来自哪里。
您可以通过各种类型的依赖注入来实现IoC。
与Java世界中的哪个位置相反，包装器可能会通过jndi的名称请求资源。 在这种情况下，代码需要它，而不是提供它。
你说过：“应用程序仍然有责任要求它使用的对象（即 - 服务），区别在于它不知道（或关心）如何创建它。”
我不认为这是真的; 组件不要求其他组件。 依赖关系是从更高层次注入的，这是一种不同的语义。 这就是IoC。
链接地址: http://www.djcxy.com/p/14429.html