Spring的IOC和AOP
IOC思想：
IOC（控制反转）是一种依赖倒置原则的代码设计的思路，它主要采用（DI）依赖注入的方式实现
不使用IOC思想的传统模式：
- 在传统模式中，对象是由程序员主动创建，控制权在程序员手中
- 程序可以做到正常工作，但仍然有一个难以避免的问题
- 如果用户的需求变更，程序员就要修改相应的代码，代码量不大还好，如果代码量巨大的话，修改一次的成本。。。
- 这个问题就是耦合度过高引起的，修改一次需求，或多或少会造成代码的修改，工作量先不说，维护起来也是极其不便的呀
- 就如上图中的四个齿轮（对象）一样，互相啮合，如果有一方停止或更换，其他的齿轮也就没办法正常工作，这自然不是我们希望看到的。
为了解决对象间耦合过高的问题，软件专家Michael Mattson提出了IoC理论，用来实现对象之间的“解耦”。
那么应当如何去达到理想的效果呢？
使用IOC思想后的模式：
IOC的主要思想是借助一个“第三方”来拆开原本耦合的对象，并将这些对象都与 “第三方” 建立联系，由第三方创建、操作这些对象，进而达到解耦的目的。
因此IOC容器也成了整个程序的核心，对象之间没有了联系（但都和IOC容器有联系）
这里引用一句知乎上看到的话
IoC的思想最核心的地方在于，资源不由使用资源的双方管理，而由不使用资源的第三方管理，这可以带来很多好处。第一，资源集中管理，实现资源的可配置和易管理。第二，降低了使用资源双方的依赖程度，也就是我们说的耦合度。
什么是控制反转？
这里我们引入一个场景， 如果A对象想调用B对象
传统模式中该如何操作，大家都很熟悉了，在A对象中创建一个B对象实例，就可以满足A对象调用B对象的需求。这是我们在A对象中主动的去创建B对象。
而引入IOC后，A对象如果想调用B对象，IOC容器会创建一个B对象注入到A对象中，这样也可以满足A对象的调用需求。但是过程由我们主动创建，变成了A对象被动的去接收IOC容器注入的B对象
A对象依赖B对象的过程，由程序员的主动创建B对象供其依赖，变为了被动的接收IOC容器注入的对象。控制权由程序员手中交到了IOC容器的手中。A对象获得依赖的过程也由主动变为被动，这就是所谓的控制反转。
什么是依赖注入？
依赖注入是IOC思想最主要的实现方式，也就是上文提到的
“A对象如果想调用B对象，IoC容器会创建一个B对象注入到A对象中，这样就可以满足A对象对B对象的依赖需求”。这个行为就是依赖注入。
DI ≠ IOC
IoC的概念更宽广一些，而DI是IoC的主要实现方式，但这并不意味着DI就是IoC，将二者混为一谈 这是不对的，很容易误导他人。
就比如你想要阅读，最主要的实现方式自然是“用眼睛长时间的去看”，但你不能把这个“眼睛长时间去看”的行为 理解为阅读。（可能例子有点不恰当）
注入方式：
- setter方法注入（常用）
- 构造器注入（常用）
- P(Property)命名空间注入
- C（Constructor）命名标签注入
