[整理] Spring 之 AOP 和 IOC
为什么要用Spring
当年的我，刚学Spring的时候，会想：『这IOC和AOP』是什么鬼玩意啊？一大堆的名词「控制反转」「依赖注入」「面向切面编程」。这是在给我搞笑的吧。
在最开始学的IOC折腾了一大堆的玩意，结果就是在管「创建对象」的事？？逗我呢？？？我直接new一个对象出来不香吗？
有这种想法明显就是「代码写得少了，想得多了」
我们写代码，不仅仅是要能实现功能，实现完了以后我们还得对写过的代码「维护」。如果我们的代码写得很烂，那「维护」的成本就很高。
维护实际上是做什么事？
- 出了问题需要找到是哪块的代码有问题
- 在原有的基础上加入一些新的功能（也就是所谓的迭代）
面对重复的/繁琐的非业务代码：
- 如果程序出了问题，我们得看吧？谁也保证不了重复的代码就没有问题。
- 我们要想加一个新的功能，还得按原来的方式写吧？代码量会越来越多，越来越多….
比如：我们的JDBC写得好好的，运行的效率也是杠杠的。但是JDBC需要我们「自行」处理的细节太多了，我们需要在里边添加各种「重复」的代码。
我们使用ORM框架，那么我们就可以更加「专注」去实现本身的业务，ORM框架把「重复」的代码都屏蔽掉，代码维护起来就比JDBC要方便。
- Spring IOC 解决的是 对象管理和对象依赖的问题。
- Spring AOP 解决的是 非业务代码抽取的问题。
Spring IOC
Spring IOC 解决的是对象管理和对象依赖的问题。本来我们的对象都是new出来的，而我们如果使用Spring 则把对象交给「IOC容器」来管理。
Spring IOC 涉及「依赖注入」和「控制反转」、「IOC容器」三个概念。
IOC 容器是什么？
我们可以理解为是一个「工厂」，我们把对象都交由这个「工厂」来管理，包括对象的创建和对象之间的依赖关系等等。等我们要用到对象的时候，就从这个「工厂」里边取出来。
「控制反转」指的就是：
本来是「由我们自己」new出来的对象，现在交给了IOC容器。把这个对象的「控制权」给「他方」了。
「控制反转」更多的是一种思想或者说是设计模式，把原有由自己掌控的事交给「别人」来处理。
「依赖注入」更多指：
是「控制反转」这个思想的实现方式：对象无需自行创建或管理它们的依赖关系，依赖关系将被「自动注入」到需要它们的对象当中去。
最简单理解「依赖注入」和「控制反转」：本来我们的对象都是「由我们自己」new出来的，现在我们把这个对象的创建权限和对象之间的依赖关系交由「IOC容器」来管理。
现在问题又来了，为什么我们要把对象给「IOC容器」来管理呢？
要理解这个，建议可以先去看看「工厂模式」
理论上，我们可以把「IOC容器」也当做是一个「工厂」，使用IOC的好处就是：
- 将对象集中统一管理，便于修改
- 降低耦合度（调用方无需自己组装，也无需关心对象的实现，直接从「IOC容器」取就好了）
IOC 需要学什么？
我们在使用Spring的时候，首先我们要学习的就是怎么把对象交给「IOC容器管理」
Spring提供了四种方式：
- 注解
- XML
- JavaConfig
- 基于Groovy DSL配置
总的来说：我们以XML配置+注解来装配Bean比较多，其中注解这种方式占大部分。
把对象放到「IOC容器」了以后，对象与对象之间是有关系的，我们需要把对象之间的依赖告诉Spring，让它来帮我们解决掉对象的依赖关系。
「对象之间的关系」别想得太复杂了。在日常开发中其实很多时候就是A对象里边有B对象的属性而已。
一般来说我们会通过构造器或者属性(setting方法)的方式来注入对象的依赖
举个例子：日常开发中，我们很多时候用@Component注解标识将对象放到「IOC容器」中，用@Autowired注解将对象注入
下面这张图就很好总结了以各种方式来对Bean的定义和注入。
Spring AOP
AOP：Aspect Object Programming 「面向切面编程」，听起来是不是很牛逼。
Spring AOP主要做的事情就是：「把重复的代码抽取，在运行的时候往业务方法上动态植入“切面类代码”」
举个例子，现在我们有以下的代码：
上面的代码其实最核心的就一行代码：「保存user对象到数据库中」
session.save(user);
我们的数据库表肯定不止user一张表，对数据库的增删改也肯定不止add()方法一个。所以我们可以想象到：对数据库的每次操作，都要写「开启事务」和「关闭事务」这种代码。
这种代码对我们来说是重复的，于是我们会想把这种代码给「抽取」出来。
如果我们单纯用OOP（面向对象）的思想去把代码给优化掉，最终我们的效果可能是这样的：
即使这样看起来代码已经很少了，但我们细想一下会发现：update()/delete()方法同样也会有aop.begin()这样的重复代码的。
我们想要「消灭」掉这些重复代码，可以怎么做？这个时候我们应该能想到「动态代理」，通过动态代理，我们可以把对象「增强」，将非业务代码写在要「增强」的逻辑上。
完了以后，我们就可以通过「增强后的对象」去调用方法，最终屏蔽掉「重复代码」.
效果可能会如下：
上面是我们手动写的代理来实现对「非业务代码」的抽取，类似这样的场景会有很多：比如我们要做权限控制，要对参数进行校验等等。
Spring 支持了AOP，让我们可以不用自己「手动」去写代理对象，达到将「非业务代码」的抽取的效果。
我们可以体验一波Spring AOP是怎么弄的，跟上面的对比对比：
效果如下：
