阶段一：概念的阐述
阶段二：从实现的角度去阐述
阶段三：举一反三的使用场景
阶段一：概念的阐述
IOC、DI是什么？IOC即控制反转，DI即依赖注入，表面上两个是不沾边的概念，其实是解决“对象与对象之间强耦合问题”的方式和方法。那么先来说一下到底IOC是一种什么样的方式，举个不恰当的栗子，A想去买一套二手房，B刚好手里有一套二手房，但是A想知道B有二手房，必须看小广告，然后打电话问（查找对象），一开始可能先给C打，可是C只想把他的二手房租出去，并不想卖，终于有一天找到了B，然后A说先把B这套房订下来（强依赖），本来以为皆大欢喜了。可是准备签合同的时候B又找到另外一个出高价的人，B告诉A说对不起不卖了，A只能哭了。这个时候扮演IOC的角色出现了，那就是房产中介D，当A想买房的时候，告诉D我要买个几室几厅的二手房；B想卖房，然后也找D登记了。D手里有很多房源和客源（IOC 容器）直接告诉A、B成交，这问题就解决了。我们回顾一下这种方式，就会发现本来由A正向控制B，这样B稍微一变就杯具了
，当D出现后，由D来反向控制A，而 D来拿到B给A的过程就是DI。理解了这一点，我们换成官方的话就是：“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”，”控制反转“把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象的思想，解决了对象与对象之间强耦合的问题
阶段二：从实现的角度去阐述
首先，在没有IOC的情况下，我们是这样强依赖的
解决容器对组件的“侵入式”管理的两种方案--主动查找和控制反转
接着，简单通过反射加配置的方式
初步实现
最后，我们使用跟spring相似的实现方式（只实现了spring三种注入方式中的set注入）
最终版
阶段三：举一反三的使用场景
除了spring 容器对bean的管理之外，我能想到的IOC场景
1.对消息的处理封装成消息中心，消息的注册和消费都在这个消费中心去做，由消息中心通过接口调用方式，注入到消费方，这样可以达到可靠的消息处理，包括失败重试
2.分布式rpc服务的注册中心
引用
http://blog.csdn.net/jiuqiyuliang/article/details/44114731