IOC - 控制反转：是一个设计原则
用来对组件之间的关系进行解耦，Spring提供了一个IOC的实现， Spring Core-IOC容器来管理组件
IOC 是一个通用的设计原则，DI（依赖注入）是具体的设计模式，它体现了IOC的设计原则
1.问题：OOP将系统分解成了一组可重用的对象，如果没有一个核心模块来管理(创建和管理)这些对象，这些对象就会仅仅的耦合在一起
1.解决方法：创建一个容器来管理，运行于容器里的对象为组件
1. 实现方法：
1.1使用接口
1.1.1问题：如果只使用接口，则对象的实现（注入）是硬编码
1.1.1解决方法：采用容器（管理对象即管理负责组成系统的组件）
1.1.2问题：如果采用了容器，那么容器负责创建了需要的所有对象（产生了依赖），并且使用类(Service类)需要容器的实例（和容器产生了依赖，并且通过字符串来说明需要具体使用哪个对象，这里是硬编码）
--（1.1.2解决方法：配置文件，将依赖从代码中转移到配置文件，容易修改和维护）
1.2问题：采用了容器，则还需要代码从容器中查找出自己所需的组件，如果更换了容器，则这些代码就需要改变
1.2解决方法：采用JEE模式--服务定位器(Service Locator)，将查找请求委托给服务定位器
1.2.1 实现：Service--调用具体对象的接口，则具体对象的注入流程：通过 ServiceLocator--Container--具体实现
IOC和DI的应用
1.3问题：组件依赖其它组件，需要主动执行查找
1.3解决方法：通过 DI 来，如setter实现，容器主动为每一个组件注入必须的资源(对象)，组件不需要主动查找，即Don't call us,we'll call you
不同的DI实现
1.4 setter方法，构造器注入
setter方法缺点：
1）. 如果组件使用者忘记注入它所需的依赖，则会发生NullPointException，并且这种情况很难调试
2）.setter注入存在安全风险，无法保证setter调用后，再次被调用而更改依赖
构造器注入PS：提供构造器之后，java将不提供默认的构造器
1.5使用配置文件配置容器
1.5.1问题：使用java代码来配置依赖关系，效率低
1.5.2解决方法：基于配置文件
1.5.3实现方法：创建配置文件--容器读取并管理组件
