标签：
AOP（Aspect-OrientedProgramming，面向方面编程），可以说是OOP（Object-Oriented Programming，面向对象编程）的补充和完善。
我们说了这么久的OOP,对于OO的理解也越来越深入,OO的伟大让我们一度折服.OOP引入封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合。可当我们需要为分散的对象引入公共行为的时候，OOP则显得无能为力。
也就是说，OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系。例如日志功能。日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。对于其他类型的代码，如安全性、异常处理和透明的持续性也是如此。这种散布在各处的无关的代码被称为横切代码，在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。
而AOP技术就不同了，它利用“横切”技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，就是我们所说的“Aspect”，切面（或方面），便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。
如果不用AOP的横切技术，我们的开发是怎样的情形呢？
1.用于日志记录的代码和业务代码缠绕在一起。复杂程度增加，容易引起混乱。
2.更改日志记录方式可能引发N处修改，即牵一发而动全身——即使可行，也会令很多人恶心吧。
所以，在系统的需求分析之初，就要利用AOP的思想，划分出核心业务和各模块公用业务，分别设计开发。说得专业一点，就是核心关注点和横切关注点。在实现了诸如日志、事务管理、权限控制等公用业务（横切关注点）的逻辑后，开发人员就可以专注于核心业务。同时，这些封装好了的公共模块，可以最大限度地复用于商业逻辑的各个部分，既不需要开发人员作特殊的编码，也不会因为修改公共模块的功能而影响具体的业务功能。
用两张图来对比说明一下AOP的好处：
第一张图中，多条业务都需要对数据对象的权限验证，所以每个业务都要分别实现权限验证的功能，或者使用同一个功能但每个业务内都要有权限验证的功能代码。
而第二张图中，多个业务所涉及的公共功能被封装成一个权限验证的公共模块，它像一把利刃，将各业务横切得到一个切面，为它们提供功能，然后又悄无声息地将业务还原。两种业务逻辑无交集。
在ITOO中，我使用filter实现。首先和各子系统约定action命名规则。异常日志和操作日志的filter代码如下：
剩余部分便是在Global中注册filter，并声明全局变量。
日志和缓存以及导入导出功能都是后期在架构上丰富起来的，作为底层开发人员，我们力求将功能和方法封装得简单易用，导入和日志两部分都是AOP的实现，为完成离散方面的分析,实际上在开发团队里指定一位精于该项工作的人员即可。
AOP的优势在于，它提供解决某一问题的持久简单的方案，这一方案强调了未来功能的重用性和易维护性：如不需要在整个应用程序中一遍遍重新编写日志代码，AOP使得仅仅编写日志方面成为可能，并且可以在这之上为整个应用程序提供新的功能。总之,需要编写的
代码量减少了… 时间节省了… 成本降低了…
标签：
原文地址：http://blog.csdn.net/zhuanzhe117/article/details/43061705
