1. IOC、DI以及AOP的本质的理解

1.1 IOC简单介绍

IOC: Inversion of Control ，被人们称为控制反转。从字面上的理解是把控制权从应用权限转移到框架中。是框架共有的特性。
对于IOC的理解，可以把IOC看作是一个生产和管理bean对象的容器。原本程序中我们要手动自己创建（new）的对象统统交给Spring的IOC容器帮我们创建。同时这就意味着，要产生的单例的bean，这个对象的生命周期也是有IOC容器管理。
IOC的产生是由于在开发的过程中产生的高度耦合性，传统的资源查找方式要求组件向容器发起请求查找资源，作为回应，容器适时的返回资源，而应用了IOC之后，则是容器主动的将资源推送给它所管理的组件，组件所要做的是仅选择一种合适的方式来接受资源，这种行为也被称为查找的被动形式。
IOC是一种将控制权转移的设计模式，由传统的程序控制转移到容器控制；

1.2 DI简单介绍

DI:Dependency Injection - 是IOC的另外一种表述的方式，被人们叫做依赖注入,主要是实现控制反转的主要的方法，将相互依赖的对象分离，在Spring的配置（注解）中描述它们之间的依赖关系，这些依赖关系也只在使用时才被建立。

1.3 依赖倒转原则

什么是依赖倒置原则？假设我们设计一辆汽车：先设计*，然后根据*大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖*。这样的设计看起来没问题，但是可维护性却很低。假设设计完工之后，上司却突然说根据市场需求的变动，要我们把车子的*设计都改大一码。这下我们就蛋疼了：因为我们是根据*的尺寸设计的底盘，*的尺寸一改，底盘的设计就得修改；同样因为我们是根据底盘设计的车身，那么车身也得改，同理汽车设计也得改——整个设计几乎都得改！
我们现在换一种思路。我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计*。这时候，依赖关系就倒置过来了：*依赖底盘， 底盘依赖车身， 车身依赖汽车。
为了理解这几个概念，我们还是用上面汽车的例子。只不过这次换成代码。我们先定义四个Class，车，车身，底盘，轮胎。然后初始化这辆车，最后跑这辆车。代码结构如下：

1.4 AOP原则

AOP（Aspect-Oriented Programming，面向方面编程），可以说是OOP（Object-Oriented Programing，面向对象编程）的补充和完善。OOP引入封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合。动态代理技术，利用截取消息的方式，对该消息进行装饰，以取代原有对象行为的执行；二是采用静态织入的 方式，引入特定的语法创建“方面”，从而使得编译器可以在编译期间织入有关“方面”的代码。然而殊途同归，实现AOP的技术特性却是相同的，分别为：

1、join point（连接点）：是程序执行中的一个精确执行点，例如类中的一个方法。它是一个抽象的概念，在实现AOP时，并不需要去定义一个join point。
2、point cut（切入点）：本质上是一个捕获连接点的结构。在AOP中，可以定义一个point cut，来捕获相关方法的调用。
3、advice（通知）：是point cut的执行代码，是执行“方面”的具体逻辑。
4、aspect（方面）：point cut和advice结合起来就是aspect，它类似于OOP中定义的一个类，但它代表的更多是对象间横向的关系。
5、introduce（引入）：为对象引入附加的方法或属性，从而达到修改对象结构的目的。有的AOP工具又将其称为mixin。

上述的技术特性组成了基本的AOP技术，大多数AOP工具均实现了这些技术。它们也可以是研究AOP技术的基本术语。

2.2.2 横切技术

“横切”是AOP的专有名词。它是一种蕴含强大力量的相对简单的设计和编程技术，尤其是用于建立松散耦合的、可扩展的企业系统时。横切技术可以使得AOP在一个给定的编程模型中穿越既定的职责部分（比如日志记录和性能优化）的操作。

如果不使用横切技术，软件开发是怎样的情形呢？在传统的程序中，由于横切行为的实现是分散的，开发人员很难对这些行为进行逻辑上的实现或更改。例 如，用于日志记录的代码和主要用于其它职责的代码缠绕在一起。根据所解决的问题的复杂程度和作用域的不同，所引起的混乱可大可小。更改一个应用程序的日志 记录策略可能涉及数百次编辑——即使可行，这也是个令人头疼的任务。

在AOP中，我们将这些具有公共逻辑的，与其他模块的核心逻辑纠缠在一起的行为称为“横切关注点（Crosscutting Concern）”，因为它跨越了给定编程模型中的典型职责界限。