控制反转依赖反转依赖注入有什么区别和联系

　　关于依赖注入如何理解，控制反转和依赖注入这两个概念有什么区别。，spring框架中的IOC跟这些概念有什么区别控制反转
　　控制反转（Inversionofcontrol）也就是IOC，spring经常会提到这个概念，可以先通过一个例子看下publicclassUserServiceTest｛publicstaticbooleandoTest（）｛。。。returntrue；｝publicstaticvoidmain（String〔〕args）｛if（doTest（））｛System。out。println（success）；｝else｛System。out。println（fail）；｝｝｝
　　上面的代码中，所有流程由程序员控制，其实可以进行一定的抽象，利用框架来实现同样的功能，如下代码publicabstractclassTestCase｛publicvoidrun（）｛if（doTest（））｛System。out。println（success）；｝else｛System。out。println（fail）；｝｝publicabstractBooleandoTest（）；｝publicclassTestApplication｛privatestaticfinalListTestCasetestCaseListnewArrayList（）；publicstaticvoiddoRegister（TestCasetestCase）｛testCaseList。add（testCase）；｝publicstaticvoidmain（String〔〕args）｛for（TestCasetestCase：testCaseList）｛testCase。run（）；｝｝｝
　　使用这个简化版的工程后，只需要在框架预留的扩展点（TestCase中的doTest抽象函数），填充具体代码就可以实现之前的功能了，不需要写负责main函数了，具体如下publicclassUserServiceTestextendsTestCase｛OverridepublicBooleandoTest（）｛returntrue；｝publicUserServiceTest（）｛注册操作还可以通过配置的方式来实现，不需要程序员显示调用register（）TestApplication。doRegister（newUserServiceTest（））；｝｝
　　以上是控制反转的例子，框架提供了一个可扩展的代码骨架，用来组装对象、管理执行流程。开发者只需要在预留的扩展点上添加跟自己业务相关的代码，就可以利用框架来驱动整个程序流程的执行。
　　这里的控制指的是对程序执行流程的控制，而反转指的是在没有使用框架之前，开发者自己控制整个程序的执行流程，使用框架之后整个利用由框架来控制。控制反转并不是一种具体的实现技巧，而是一个比较笼统的思想，一般用来指导框架的顶层设计依赖注入
　　依赖注入跟控制反转恰恰相反，它是一种具体的编码技巧。用一句话来概括就是：不通过new（）的方式在类内部创建依赖对象，而是将依赖的类对象在外部创建好通过构造方法、函数参数等方式传递给类使用非依赖注入方式publicclassNotification｛privateMessageSendermessageSender；publicNotification（）｛this。messageSendernewMessageSender（）；｝publicvoidsendMessage（）｛messageSender。sendMessage（）；｝｝publicclassMessageSender｛publicvoidsendMessage（）｛。。。。｝｝依赖注入方式publicclassNotification｛privateMessageSendermessageSender；publicNotification（MessageSendermessageSender）｛this。messageSendermessageSender；｝publicvoidsendMessage（）｛this。messageSender。sendMessage（）；｝｝
　　通过依赖注入的方式将依赖的类对象传递进来，提高了代码的扩展性，可以灵活的替换依赖类，这样也比较符合开闭原则。我们还可以把MessageSender定义成接口，基于接口而非实现类编程，改造如下publicclassNotification｛privateMessageSendermessageSender；publicNotification（MessageSendermessageSender）｛this。messageSendermessageSender；｝publicvoidsendMessage（）｛this。messageSender。sendMessage（）；｝｝publicinterfaceMessageSender｛voidsendMessage（）；｝publicclassSmsSenderimplementsMessageSender｛OverridepublicvoidsendMessage（）｛｝｝
　　上面的例子就是依赖注入，其实在日常的开发中非常常用依赖注入框架
　　我们继续看下什么是依赖注入框架，继续使用刚才的例子来说明，在采用依赖注入实现的Notification中，不用在类内部通过new来创建MessageSender对象，但是创建对象、组装对象的工作仅仅被移动到了更上层的代码而已，具体如下publicclassDemo｛publicstaticvoidmain（String〔〕args）｛MessageSendersmsSendernewSmsSender（）；NotificationnotificationnewNotification（smsSender）；notification。sendMessage（）；｝｝
　　在实际的软件开发中，项目可能涉及到上百个类，类对象的创建和依赖会变得非常麻烦，所以像对象创建和依赖注入的工作，本身和业务无关，完全可以抽象成框架自动完成
　　这个框架就是依赖注入框架。我们只需要通过依赖注入框架提供的扩展点，简单配置一下所有需要创建的类对象、类与类之间的依赖关系，就可以实现由框架来自动创建对象、管理对象的生命周期、依赖注入等原本需要程序员来做的事情。
　　实际上，现成的依赖注入框架有很多，最典型的就是Spring依赖反转原则
　　前面讲了控制反转、依赖注入、依赖注入框架，最后讲下依赖反转原则。依赖反转原则的英文翻译是DependencyInversionPrinciple，缩写为DIP。中文翻译有时候也叫依赖倒置原则。
　　主要的概念是：高层模块（highlevelmodules）不要依赖低层模块（lowlevel）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。所谓高层模块和低层模块的划分，简单来说就是，在调用链上，调用者属于高层，被调用者属于低层。在平时的业务代码开发中，高层模块依赖底层模块是没有任何问题的。实际上，这条原则主要还是用来指导框架层面的设计，跟前面讲到的控制反转类似。我们拿Tomcat这个Servlet容器作为例子来解释一下。
　　Tomcat是运行JavaWeb应用程序的容器。我们编写的Web应用程序代码只需要部署在Tomcat容器下，便可以被Tomcat容器调用执行。按照之前的划分原则，Tomcat就是高层模块，我们编写的Web应用程序代码就是低层模块。Tomcat和应用程序代码之间并没有直接的依赖关系，两者都依赖同一个抽象，也就是Sevlet规范。Servlet规范不依赖具体的Tomcat容器和应用程序的实现细节，而Tomcat容器和应用程序依赖Servlet规范。
　　不闻不若闻之，闻之不若见之，见之不若知之，知之不若行之