Spring AOP概述
AOP的概述
编程语言的最终的目标是以更自然， 更灵活的方式模拟这个世界，从原始机器语言到过程语言再到面向语言，编程语言一步步地用更自然，更灵活的方式描述软件。AOP是软件开发思想发展到一定阶段的产物，但AOP的出现并不是完全一代了OOP，而仅是作为OOP的有益补充，虽然AOP作为一项编程技术已经有多年的历史，但一直长时间停留在学术领域，直到近几年，AOP才作为一项真正使用的技术在应用领域开疆扩土。需要指出的是AOP的应用场合是有限制的，它一般只使用与那些具有横切逻辑的应用场合：如性能检测，访问控制，事物管理以及日志记录（虽然很多文章用日志记录来作为讲解AOP的实例，但很多人认为很难用AOP编写程序日志，博主对此观点非常赞同。）不过这丝毫不影响AOP作为一项新的软件开发思想在软件开发领域所占有的地位。
（1）AOP到底是什么？
AOP
（Aspect-OrientedProgramming的简称），最初被译为“面向方面编程”，这个翻译想来为人所诟病，但是由于先入为主的效应，受众广泛，所以这个翻译被很多人使用，但我更倾向于用“”面向切面编程”的译法，因为它更加达意。
按照软件重构思想的理念，如果多各类中出现相同的代码，应该考虑定义一个共同的抽象类，将这些相同的代码提取封装到一个抽象类当中，比如Dog、Cat、Pig都有run()跟eat()的方法，用过引用一个包含这两个方法抽象的Animal父类，Dog、Cat、Pig就可以通过继承Animal复用到run()和eat()的方法。通过引用父类消除多个类中重复代码的形式大多数情况是可行的，但世界并非永远这样简单，请看下面的代码：
上面代码斜体部分是性能监控的代码，它在方法调用前启动，在方法调用返回前结束，并在内部记录性能的结果信息，而黑色粗体的代码是事务和事务提交的代码，我们发现@1，@2处业务代码淹没在重复化非业务性的代码之中，性能监控和事务管理这些非业务性代码葛藤缠树般保卫者业务性代码。
假设我们将FormService业务类看成一段圆木，将removeTopic()和createForum()方法分别看成圆木一截，我们会发现性能监视和事务管理的代码就好像一个年轮，而业务代码就是圆木的树心，这也正是横切代码概念的由来。
横切逻辑示意图
我们无法通过抽象父类的方式消除以上所示的重复性代码，因为这些横切逻辑依附在业务类方法的流程中，他们不能转移到其他地方去。
AOP独辟蹊径通过横向抽取机制为这类无法用过纵向继承体系进行抽象的重复代码提供解决方案。对于习惯了纵向抽取的开发者来说，可能不理解横向抽取方法的工作机制，因为Java语言本身不直接提供这种横向抽象的能力，我们暂把具体实现放在一旁，先通过图解的方式会拿出AOP的解决思路，如下图
横线抽取
从图中，我们可以看出AOP希望将这些分散在各个业务逻辑代码中的相同代码，通过横向切割的方式抽取到一个独立的模块中，还业务逻辑类一个清新的世界。
当然，我们知道将这些重复的横切逻辑独立出来是很容易的，但如何将这些独立的逻辑融合到业务逻辑中完成和原来一样的业务操作，这才是事情的关键，也正是AOP要解决的主要问题。