Spring IOC和DI以及AOP理解

概述

这三个概念可能大家都不陌生，在面试中经常会出现关于此类的问题，关于对他们的个人理解如下。

IOC

IOC其实就是控制反转，控制指的是对象的创建、管理、实例化权利，反转指的是控制权交给了外部容器Spring框架，打个比喻，我在项目中创造了一个对象类，在业务层需要用到他了，一般的办法是什么？是不是new对象啊，毕竟程序猿最擅长new对象了，而new对象就意味着依赖性增强，那么我不new行不行呢，这个时候IOC就出场了，IOC容器能帮助我们实例化对象并且管理它，当我们需要使⽤哪个对象，直接去问IOC容器要即可，是不是非常方便。从演化过程可以划分成五代:第一代通过自己new对象；第二代通过使用接口来实现；第三代就转化成Bean工厂，通过工厂来创建对象；第四代服务中心代理模式，通过注册到服务中心然后从服务中心获取；最后一代set注入，进行IOC容器管理

DI

大家都知道IOC其实和DI是同样的一个东西，既然是同一个东西，那为什么又会诞生他呢？DI，称之为依赖注入，他也是搞对象实例化和依赖关系维护这件事情，但是角度不同，IOC是站在对象的角度，我这个对象需要实例化，而DI是站在容器的角度，容器会把对象依赖的其他对象注入。比如A对象在实例化过程中声明了一个B类型的属性，就要容器把B对象注入A。

AOP

AOP是OOP的延续，传统OOP三大特性封装、继承、多态，成一种垂直继承体系，但是存在顶级分类代码重复无法优化问题，无法解决横向切面逻辑代码问题，所以就产生了AOP，通过横向抽取机制，将横切逻辑代码和业务逻辑代码分离。在不改变原有业务逻辑情况下，增强横切逻辑代码，根本上解耦合，避免横切逻辑代码重复。

实际场景

比如我有一个老项目，以前就根本没考虑到日志打印记录这个问题，现在需求来了，需要在所有控制层增加日志打印，最笨的办法就是一个个控制层方法添加咯，或者在优化一哈，写一个工具类，然后再引入每一个方法，不管怎样，都要去动原有的代码逻辑才能实现，这时候如果借助AOP我们就可以实现对所有方法的拦截，通过动态代理技术，实现在原方法执行前和执行后业务逻辑的增强，是不是很简单，我甚至都不用去动原来的代码就实现了这个需求，这就是AOP。