早上起来占个坑，晚上整理。
依赖注入DI(dependency injection)：
谁依赖谁？谁注入谁？注入什么？
调用类依赖功能类。
容器注入调用类。
注入了功能类的实例。
控制反转Ioc(inversion of control):
谁控制谁？反转了什么？正转是什么？
ioc容器控制实例的创建和管理、注入。
反转了实例的创建方，由调用类转移到Ioc容器中。
正转是在调用类中主动创建功能类的实例，控制它的生命周期。
依赖注入和控制反转的区别？
依赖注入和控制反转不是一门技术，而是一种通过注入依赖对象来实现解耦的设计思想，是程序设计的一个基本设计原则。
所以，对它们没有明确的技术界限的定义，仁者见仁智者见智，各自有各自的理解。重点是其中的注入依赖对象的解耦思想。
这种设计原则，设计思想初期从控制权的角度称作Ioc，但2004年一个技术大牛认为控制反转不太贴切，提出了依赖注入这个概念。其实无论依赖注入还是控制反转，他们只是对同一设计思想，在不同方面理解下的称呼而已，并无实质区别。
spring 的Ioc容器在这一设计原则下做了什么？
将调用类所有依赖的对象通过注入的方式赋予调用类，实现了最大程度的解耦合（调用类只需认识功能类的接口和Ioc容器）。
但是这样虽然不必再让调用类去认识所有的ICar的实际类，只需要认识一个ICar接口，降低了耦合度，但产生了一个问题，
创建一个Person实例时，我还需要创建一个ICar的实例，然后手动注入Person实例，如果Person类还依赖于许多类，那么当创建一个Person实例就需要同时创建许多个功能类实例，然后再手动注入Person中，这样太累了，，，
而我又想用这种设计方法来降低我的代码耦合度，又不想创建一个实例这么麻烦地做这么多工作，怎么办呢，，，
spring Ioc登场，框架就是来为开发者省时省力的（学框架虽然麻烦，但学会它会给你省去更多的麻烦，超值！！！安慰自己）
通过spring Ioc容器，我们只需在Beans中配置类的实例化参数，和他们之间的依赖关系，就可以像传统地开发方式一样轻松地创建类地实例对象了
ApplicationContext context=new ClassPathXmlApplicationContext();
Person p1=context.getBean("p1");//通过id创建
Person p2=context.getBean(Person.class);//通过类型创建
关于如何通过配置，选择不同的初始化方法，注入类的属性参数、依赖对象，可以通过进一步学习掌握啦。
（其实想想spring Ioc的容器管理和mybatis的sql管理相似，先配置xml文件、创建框架的工厂，工厂通过id或其他参数调用具体实例，核心思想很相似。看得多了大致都是这样）
所以，：
依赖注入和控制反转只是对这同一种设计原则的不同称呼，搞明白这种设计思想的原理、用处、优点、精妙之处后，
其明确，界限分明的定义如何阐述就不重要了，在你心中就有了自己的一套解释。