啥是IOC，DI，AOP

初学spring框架必须要了解的三个核心。相关文章也特别多，自己对这些知识进行归纳总结，更简单的描述下是个啥玩意。

IOC， DI， AOP是个啥玩意，为啥要有这三个东西

这三是面向对象编程的一种思想，也是Spring框架的最主要的三个核心。为了编写出更易于维护和扩展的程序而发明出来的。

IOC（控制反转）

用最好理解的描述来说： 我们不再去new一个对象，而是让框架来帮我们创建我们想要的对象。

为什么我们要让框架去帮我们生成一个对象而不是我们自己去new一个呢？按照原先我们写程序的习惯，自己new一个完全没啥问题呀，平时new着也挺好的。但是当我们的程序功能越来越多的时候，会发现自己的程序修改起来会越来越麻烦，想要加一个简单的功能都会让自己非常甚至于偶尔会有种想重新写一遍的冲动。

讲重点：
让框架帮我们去创建对象，实际上框架在创建对象的时候可以根据我们的意愿对这些我们自己写的类进行一些特殊的处理，这里要提到23种设计模式，等我们拿到我们的对象的时候，这个对象可以说已经不是我们当初写的那个类而产生的了，已经是加了buff的实体类了。比如：

• 自动帮我们装填数据
• 让我们每次获得的对象都是同一个对象（传说中的单例模式）
• 插入一个方法到对象里面
• 在运行某个方法的前后再插入一些动作
• 等等我们想要做的一些处理

听起来是格外的神奇呢，看起来可以帮我们做不少事情，少些不少代码，不过还是挺懵逼，是怎么办到这些神奇的操作的呢？

---

实现这种神奇功能的思路：

1. 先获得需要的类
2. 然后用java提供的反射api对这个类进行解析
3. 然后对这个类加一些buff（指定的一些操作）
4. 返回修改之后的对象

23种设计模式是框架来实现这些神奇操作的手段

---

DI （依赖注入）

用最好理解的描述来说： 把对象里面需要的属性给你直接创建好，不用我们去给对象赋值来初始化。

框架又帮我们偷了点懒，连属性都不用让我们自己去赋值了，但是为啥要这么去做呢，有必要让框架帮我们偷这个懒吗？

这个明显的看出DI 是需要 IOC的。依赖注入的过程是IOC容器在创建对象时候的反射查看了对象的属性然后把我们需要的参数或者实现类注入进来，效果看起来就像我们创建一个对象，里面的属性都没有初始化，但是就是可以直接用。

其实帮我们去把这个类里面的属性直接给我们处理好不是为了让我们写代码偷懒的，而是为了让我们写的类更加的灵活好扩展，如何体现出来的呢？举个例子：

1. 我们写了一个计算的接口，主要用来计算两个数相乘的结果
2. 然后我们写了一个类实现这个接口，实现了两个数相乘的功能
3. 然后我们在一个计算器的类里面加上了我们写的这个接口，创建计算器的类的时候会创建接口的实体类
4. 功能实现了

但是现在加了一个新的需求，我们需要计算复数对象相乘的结果（需求听起来很奇怪，实际是很多时候的需求都很奇怪），如果按照我们最习惯的做法是直接写个实现类，然后把计算器类里面的实现类换一下，然后来修改功能。

然而需求方第二天又要要求改回之前的样子，这下就难受了，我又得修改代码重新打包发给客户。

此时，依赖注入的好处就可以体现出来了，我们的对象里的依赖属性不是我们直接用代码放进去的，而是框架根据某个配置文件帮助我们放到对象里面的。此刻我们只需要更改配置文件的依赖关系就修改了 计算器类 里 接口的实现类。给客户发个消息， 告诉他把配置文件的一个位置修改下重启下程序就ok了。

程序变得更加好维护了，DI是个好东西。

AOP （面向切面）

用最好理解的话来说： 我们的程序的功能模块现在是一片一片的插入进来的，不要了抽出去行

听起来挺好，加功能去功能拔插即可。以前写个代码加个功能去个功能到处改，难受死，还容易把程序给弄凉了。

在程序做好之后现在需要做一个做一个统计的功能，统计用户调用每个功能的频率，使用次数。第一反应就是我们的程序需要大量的修改代码，在所有的api执行的时候做一次记录，首先想到的解决方案就是在每个接口实现里面加代码来实现这个功能。明显可以感觉到加这种功能是多么的让人难受，如此简单的功能却要修改大量的代码来实，着实让人难以接收。

AOP就是用来解决此类类似问题的，AOP的思想是需要IOC和DI作为支撑，框架用IOC容器控制整个程序的所有API对象的生成，在这种前提条件下，我们只需要在所有的API生成的时候插入一个计数的方法，即可实现这个功能。框架在IOC/DI的支撑下顺带实现了AOP的思想。

总结

这些三个思想基本都要用到java的反射来实现，23种设计模式是IOC/DI实现主要手段。 开发的时候我们常常要把已经开发好的功能再拆分成更小的模块更，更细致的功能，为了尽可能的不修改过去的代码来插入新的功能，此时就需要AOP的思想来设计程序了。一切都是为了程序更好迭代开发和维护而产生。