一个问题
面向过程------
想象一个过程----当我们的计算机技术还没有这么发达的时候，所有的代码，就是建立在面向过程的。
这种代码模式带来一个重要的问题，大项目的程序在写的过程中，会有相当的代码量是冗余重复的。
不仅仅耗时耗力，一不小心就可能让我们的整个工程出现坍塌事故。
面向对象------
我们在写代码的过程中，发现很多的代码实例都是重复的，他们仅仅需要一个参数实例化，这样一样的代码就能起到不一样的
作用，面向对象的编程出现了，一切皆可对象化，对象的实例化就是参数转移的过程。
一个问题？------
注意上述过程，当我们在写一个项目的时候，所有的代码建立在类上，类与类之间有一定的依赖关系，倘若你的工程
中有个类跟其他的类一点关系也没有，那你可以把这个类删掉了，因为它很可能没有被编译。
现在有个问题，创建一个项目需要不同的类之间的依赖关系，那么当我们的这个项目有大的变动时，修改其中的一个类
其他的类及代码是否也需要改变？答案是肯定的，那么在这个过程中，可想而知，重复的工作和没必要的代码以及重新搭建
的工程是怎么样的耗时耗力不讨好的过程了。
耦合与依赖
耦合就是项目中类与类之间的依赖关系，就像学生和班级的关系，学生的班级改变后，对应的班主任也不一样。
类与类之间的依赖越多越深，类与类之间的耦合越大。
接口
接口是抽象的类，其所有的方法和属性都是抽象的，我们在使用它的时候需要先实例化，创建一个类来实现它。
容器和依赖注入
通过以上描述，当前需要解决的问题是，有没有一种模式，让我们在进行类的使用的时候，
可以根据我们的需要进行不同的类之间的依赖关系的重新设置——即依赖注入。
当类和类之间的关系变得可控的时候，以上提出的问题都能够被解决。
两个思路
1.我们知道类和类之间之所以出现耦合的关系，是因为对象有自己特定的实例化的时间和过程，即班级的对象必定要在
学生对象之前出现。
基于此，如果我们能够控制类创建对象的时间，就能够伪实现类和类的耦合，为什么是伪实现，因为即使控制了不同
的类创建对象的时间，但是类与类时间的书写关系并没有改变。
2.当所有的类都分离，借用第三方的容器，该容器拥有所有类的使用权，你只需要告诉它什么时候创建哪个对象，并和哪个类
有什么的关系，这样我们就实现了类和类之间的无耦合关系。
上述两个解决方案，显然第二个更值得尝试。
IOC控制反转机制—面向接口编程----DI依赖注入模式
控制反转IOC---将组件间的依赖关系在系统中抽离出来。
依赖注入DI-----将组件间的依赖关系通过外部传参的方式注入。
这里我们提出两个概念 IOC 和 DI 来实现我们上面提到的第二个解决方案。首先编程的过程中进行IOC再根据我们的需要进行DI
依赖前和解决问题后的模式如下所示：
代码层面的逻辑
可以参考这篇博客
代码层面来看IOC思想