aop的使用场景

传统的OOP程序经常表现出一些不自然的现象，核心业务中总掺杂着一些不相关联的特殊业务，如日志记录，权限验证，事务控制，性能检测，错误信息检测等等，这些特殊业务可以说和核心业务没有根本上的关联而且核心业务也不关心。

这些特殊业务会带来哪些问题呢？

1.代码混乱，大量的外围操作可能会混乱核心操作的代码，而且当外围模块有重大修改时也会影响到核心模块。

2.代码分散和冗余：同样的功能代码，在其他的模块几乎随处可见，导致代码分散并且冗余度高。

3.代码质量低扩展难：由于不太相关的业务代码混杂在一起，无法专注核心业务代码，当进行类似无关业务扩展时又会直接涉及到核心业务的代码，导致拓展性低。

解决：

假设现在我们把日志、权限、事务、性能监测等外围业务看作单独的关注点(也可以理解为单独的模块)，每个关注点都可以在需要它们的时刻及时被运用而且无需提前整合到核心模块中。将每个关注点与核心业务模块分离，作为单独的功能，横切几个核心业务模块。

aop使用场景介绍
一，性能统计／计数

说到＂优化＂，我们要做的第一件事是知道要优化什么（定位系统瓶颈／优化点）～

比如，我们需要知道方法执行时间／调用次数等信息～

常识告诉你，把这部分＂业务无关＂的逻辑写入＂业务代码＂是非常不合理的，你可能需要在每个需要＂监控＂方法前后埋点（方法运行前打开计时器，离开方法后（前）停止计时器），在每个方法前干一遍（哪怕只是简单的调用两个方法）是一件很蠢的事情；另外，可能系统运行一段时间后，你得到了需要的数据可能需要关闭这个功能（完美主义者可能无法容忍这种其实可以忽略不计的性能消耗），你需要自己实现一个stopwatch，在逻辑中读取一个开关来确定是否关闭这个功能，要不然你就得改一遍所有的方法，把这部分代码全部去掉～

更好方法就是AOP拦截他们～你可能会考虑perf4j，使用注解的方式去拦截需要性能统计的方法～

也可以自己实现这种功能，通过全局的配置在service/dao这种层级方法上面的拦截器这个事情，等到你搜集完需要的数据之后，你可以通过注释掉配置关闭这个功能～

二，事务处理

用AOP做事务处理的场景是最常见的，我们一般在＂事务方法＂前打开一个事务，离开方法后提交事务，方法抛出异常时对事务进行回滚～其实其他资源的打开和关闭的场景你也可以考虑这种方法；

三，缓存处理

缓存按照＂粒度／功能＂可以分为：页面缓存，方法缓存／查询缓存，数据缓存（对Entity／数据记录进行缓存）等；

简单的＂方法缓存＂可以把＂方法名－参数＂作为Key，拦截器拦截方法根据＂方法名－参数＂去缓存系统查询，如果存在就直接返回，不需要执行方法真正的逻辑～

其他类型的缓存思路其实也差不多～

四，协议转换

五，日志打印

调试／开发的时候我为了方便会将DAO层方法全部拦截，然后将返回数据打印出来（往往使用JSON或者在控制台打印一个表格）～

六，其他场景

数据加加密/签名／验签名等场景；

支付行业往往对安全性要求比较高，我们在保存／接收／发送数据前先要对数据进行验签／签名／加密等操作，甚至数据在保存到数据库的时候都需要做特殊处理，比如一个手机号13812348888，我们需要在保存前将它变成138[密文]8888这种形式，我们可以通过一个＂拦截器＂对手机号，身份证号这种敏感信息做这种特殊处理；

如果你的接口需要对某些字段进行签名，然后set到一个指定的字段，这种时候AOP也非常有用；

还有就是异常通知这种业务无关逻辑，你可以拦截一些要紧的方法，如果方法返回失败或者抛出异常，你可以异步的调用一个通知方法发送一个邮件或者短信什么的，这样你就能立即知道问题了（当然其实有更好的异常监控方法，我只是打个比方）～