Spring AOP 剖析（1）

软件开发的目的，最终是为了解决各种需求，包括业务需求和系统需求。使用面向对象的方法，可以对业务需求等普通关注点进行很好的抽象和封装，并且使之模块化。

 

但是对于系统需求一类的关注点来说，情况却有所不同。

 

 

 

 

1. 对于业务的需求而言，需求与其具体实现之间的关系基本上是一对一的。可以在系统中的某一个确定的点找到针对这种需求的实现，无论从开发还是维护的角度，都比较方便。

 

一个关于贷款业务的系统功能模块划分示意图

 

2. 对于系统需求，比如：为了对系统进行监控，需要为所有这些业务需求的实现添加日志记录功能，或者业务方法的执行需要一定的权限限制。要将这些需求以面向对象的方式实现并集成到整个系统中去，可就不是一个需求对应一个实现那么简单了。系统中的每个业务对象都需要加入日志记录，加入相应的安全检查，那么这些需求的实现代码就会遍及所有的业务对象。

 

系统中普通的业务关注点，OOP可以很好地对其进行分解并使之模块化，但却无法更好地避免类似于系统需求的实现在系统中各处散落的问题。为了解决这个问题，于是AOP应运而生。

 

 

日志记录，安全检查，事务管理等系统需求就像一把刀横切在组织良好的各个业务功能模块之上

 这些系统需求是系统中的横切关注点，使用传统方法，无法更好的以模块化的方式，对这些横切关注点进行组织和实现。

所以 AOP 引入了 Aspect 的概念，用来以模块化的形式对系统中的横切关注点进行封装。

 

Aspect 对于 AOP ，就相当于 Class 对于 OOP。 AOP 仅是对 OOP 方法的一种补足，当把以 Class 形式模块化的业务需求和以 Aspect 形式模块化的系统需求拼装到一起的时候，整个系统就算完成了。