OOP应用开发面临的问题
面向对象技术很好地解决了软件系统中角色划分的问题。借助于面向对象的分析、设计和实现技术，开发者可以将问题领域的“名词”转换成软件系统中的对象，从而很自然地完成从问题到软件的转换。
但是，问题领域的某些需求却偏偏不是用这样的“名词”来描述的。比如遇到这样的问题：需要对系统中的某些方法进行权限检验，这种需要权限检验的方法散布在40多个类中。面对这种需求，应该怎么办呢？最直接的办法就是：创建一个起类（或接口），将权限检验的功能放在其中，并让所有需要权限检验的类继承这个起类（或接口）．如果这个需求是后期提出的．需要修改的地方就会分散在40多个文件中。这样大的修改量，无疑会增加出错的几率，并且加大系统维护的难度。
人们认识到，传统的程序经常表现出一些不能自然地适合单个程序模块或者几个紧密相关的程序模块的行为例如权限检验、日志记录、对上下文敏感的错误处理、性能优化以及设计模式等等、我们将这种行为称为“横切关注点（crosscuttingconcern）”，因为它跨越了给定编程模型中的典型职责界限。如果使用过用于横切关注点的代码，您就会知道缺乏模块性所带来的问题。因为横切行为的实现是分散的，开发人员发现这种行为难以作逻辑思维、实现和更改。
AOP是什么？
AOP是OOP的延续，是Aspect Oriented Programming的缩写，意思是面向方面编程。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。在J2EE应用开发中，我们主要用到AOP的拦截（interception）能力，它为我们提供了“在任何对象的方法调用前/后加入自定义行为”的能力，这使得我们可以处理企业应用中的横切（crosscutting）关注点（即：同时作用于多个对象的关注点），并且仍然保持强类型（不需要改变方法签名）。
举例：假设有在一个应用系统中，有一个共享的数据必须被并发同时访问，首先，将这个数据封装在数据对象中，称为Data Class，同时，将有多个访问类，专门用于在同一时刻访问这同一个数据对象。
为了完成上述并发访问同一资源的功能，需要引入锁Lock的概念，也就是说，某个时刻，当有一个访问类访问这个数据对象时，这个数据对象必须上锁Locked，用完后就立即解锁unLocked，再供其它访问类访问。
使用传统的编程习惯，我们会创建一个抽象类，所有的访问类继承这个抽象父类，如下：
abstract class Worker...{
abstract void locked(); abstract void accessDataObject(); abstract void unlocked();
}
缺点：
- accessDataObject()方法需要有“锁”状态之类的相关代码。
- Java只提供了单继承，因此具体访问类只能继承这个父类，如果具体访问类还要继承其它父类，比如另外一个如Worker的父类，将无法方便实现。
- 重用被打折扣，具体访问类因为也包含“锁”状态之类的相关代码，只能被重用在相关有“锁”的场合，重用范围很窄。
仔细研究这个应用的“锁”，它其实有下列特性：
- “锁”功能不是具体访问类的首要或主要功能，访问类主要功能是访问数据对象，例如读取数据或更改动作。
- “锁”行为其实是和具体访问类的主要功能可以独立、区分开来的。
- “锁”功能其实是这个系统的一个纵向切面，涉及许多类、许多类的方法。如下图：
因此，一个新的程序结构应该是关注系统的纵向切面，例如这个应用的“锁”功能，这个新的程序结构就是aspect（方面）
在这个应用中，“锁”方面（aspect）应该有以下职责：
提供一些必备的功能，对被访问对象实现加锁或解锁功能。以保证所有在修改数据对象的操作之前能够调用lock()加锁，在它使用完成后，调用unlock()解锁。
权限控制的应用程序实现
对于权限管理的做法，在WEB实现上，有以下几种：
⑴ 利用Filter，对所有进入的URI进行解析，并取得当时Session中的User信息，然后通过RBAC的机制，将此链接需要的权限与用户拥有的权限进行比较，然后进行相应的处理。这种做法有很多好处：简单，容易实现，并且对系统侵入性也不强。这里URL就是RBAC中的资源了。这样做的缺点是所有对数据的操作必须通过URL来体现，这一点在现代的程序中不太好实现。如果采用Struts, XWork或者Tapestry，采用同一个URL（浏览器看来）进行处理多项任务已不是什么稀奇的事。
⑵ 利用一个BaseServlet(Servlet+Jsp经典模式)或者BaseAction(Struts模式)或者BasePage(Tapestry模式)或者BaseController(SpringMVC模式)，对所有的请求先进行过滤进行权限操作，然后再处理。稍微看一下就知道这种模式跟Filter并无本质不同。优缺点同上。
那么，如果要实现更为细致的权限操作，精确到某个方法的权限，典型的做法如下：
public someFunciton() ...{ //权限判断 User user = context.getUser();
if (user.canExecuteThisFunction()) ...{ // do the business method // ... } else ...{ throw new PermissionDeniedException();
}} 这种做法能够将权限的粒度控制到具体的业务方法，因此它的控制能力应该是强大的。可以看到，权限判断部分对于每个方法几乎是独立的。
这种在具体功能前加入权限操作检验的实现方式有很多缺点：
⑴ 每个功能类都需要相应的权限检验代码，将程序功能和权限检验混淆在一起，存在紧密的耦合性，扩展修改难度大。
⑵ 以代理模式为每个功能类实现一个相应的代理类，虽然解耦了程序功能和权限检验，但是，从某个角色的权限检验这个切面考虑，涉及具体Proxy类太多，扩展修改难度大。
权限控制的J2EE容器实现
在AOP概念没有诞生前，J2EE规范已经提供了关于权限控制的容器实现标准，这种变迁结果如下图所示：
 图2 权限控制的J2EE容器实现 |
原来需要每个应用程序实现的权限Proxy转为整个容器的Proxy实现，其中JDK1.3以后的动态代理API为这种转换实现提供了技术保证。
非常明显，通过容器实现权限控制验证可以大大简化应用程序的设计，分离了应用系统的权限关注，将权限控制变成了对J2EE容器服务器的配置工作。
其实，容器的权限实现也是一种从一个侧面来解决问题方式，AOP概念诞生后，权限控制实现由此也带来了两个方向的变化：
⑴ J2EE容器级别的权限实现，也就是容器自身的权限实现。
⑵ J2EE应用程序级别的权限实现。
权限控制在容器级别实现似乎使得J2EE开发者感觉没有灵活性和可扩展性，其实象JBoss 4.0这样的J2EE容器，由于引入了AOP概念，使得J2EE开发者在自己的应用系统中能够直接操纵容器的一些行为。容器和应用系统由于AOP引入的Aspect切面，变得可以成为一体了。
对于J2EE应用系统开发者，能够做到上述境界，必须的条件是对JBoss之类J2EE容器必须有足够的了解，因为这些方式并不是J2EE标准，有可能在移植到新的J2EE容器，这些知识和投入变得无用（也有可能将来J2EE扩展其标准）。
很显然，使用AOP实现J2EE应用系统级别的权限控制，是解决上述移植风险的一个主要方法，但是带来的缺点是必须亲自从零开始做起，耗费时间不会很短。
AOP下的权限控制实现
有了AOP，新的业务方法可以这样写：
public someFunciton() ...{ // do the business method // ...} 没有了额外的权限操作，这个业务方法看起来那么清晰自然。
将对权限的操作作为一个Advice，并将Advisor关注到所有的业务方法（可能有某一个特定package），然后，剩下的事情就由RBAC以及AOP来完成了。通过这样的分离，纵向的一个业务方法被分割为一个更为自然的业务方法和一个关注点。这个关注点写法可能如下：
public class PermissionCheckAdvice implements MethodBeforeAdvice ...{ public void before(Method arg0, Object[] arg1, Object arg2) throws Throwable ...{ //权限判断 if (!this.getContext().getUser().canExcute(this, arg0)) ...{ throws new PermissionDeniedException(); } }} 可能有个问题：如何取得context或者当时上下文环境的User呢？答案是使用IoC（或称Dependency Injection），将上下文环境或者User作为参数反向传入到逻辑方法中。当然，在传入之前，这些变量是需要初始化的。这个初始化工作可以在SuperServlet中进行，并且以Session单例的形式保存在应用程序中。下面是Spring配置文件的例子：
＜beans＞＜!-- Bean configuration --＞＜bean id="businesslogicbean"class="org.springframework.aop.framework.ProxyFactoryBean"＞＜property name="proxyInterfaces"＞＜value＞IBusinessLogic＜/value＞＜/property＞＜property name="target"＞＜ref local="beanTarget"/＞＜/property＞＜property name="interceptorNames"＞＜list＞＜value＞thePermissionCheckBeforeAdvisor＜/value＞＜/list＞＜/property＞＜/bean＞＜!-- Bean Classes --＞＜bean id="beanTarget" class="BusinessLogic"＞＜property name="user"＞＜＜YOUR USER OBJECT＞＞ ＜/property＞＜/bean＞＜!-- Advisor pointcut definition for before advice --＞＜bean id="thePermissionCheckBeforeAdvisor"class="org.springframework.aop.support.RegexpMethodPointcutAdvisor"＞＜property name="advice"＞＜ref local="thePermissionCheckBeforeAdvice"/＞＜/property＞＜property name="pattern"＞＜value＞.*＜/value＞＜/property＞＜/bean＞＜!-- Advice classes --＞＜bean id="thePermissionCheckBeforeAdvice" class="PermissionCheckBeforeAdvice"/＞ ＜/beans＞AOP引进了Aspect，它将影响多个类的行为封装到一个可重用模块中，它允许程序员对横切关注点进行模块化，从而消除了OOP引起的代码混乱和分散问题，增强了系统的可维护性和代码的重用性。利用AOP的拦截（interception）能力，它为我们提供了“在任何对象的方法调用前/后加入自定义行为”的能力，这使得我们可以处理企业应用中的权限控制这一横切关注点，并且仍然保持强类型（不需要改变方法签名），解耦了程序功能和权限检验。
AOP应用范围
很明显，AOP非常适合开发J2EE容器服务器，目前JBoss 4.0正是使用AOP框架进行开发。
具体功能如下：
Authentication 权限
Caching 缓存
Context passing 内容传递
Error handling 错误处理
Lazy loading 懒加载
Debugging 调试
logging, tracing, profiling and monitoring 记录跟踪 优化 校准
Performance optimization 性能优化
Persistence 持久化
Resource pooling 资源池
Synchronization 同步
Transactions 事务
AOP有必要吗？
当然，上述应用范例在没有使用AOP情况下，也得到了解决，例如JBoss 3.XXX也提供了上述应用功能，但是没有使用AOP。
但是，使用AOP可以让我们从一个更高的抽象概念来理解软件系统，AOP也许提供一种有价值的工具。可以这么说：因为使用AOP结构，现在JBoss 4.0的源码要比JBoss 3.X容易理解多了，这对于一个大型复杂系统来说是非常重要的。
从另外一个方面说，好像不是所有的人都需要关心AOP，它可能是一种架构设计的选择，如果选择J2EE系统，AOP关注的上述通用方面都已经被J2EE容器实现了，J2EE应用系统开发者可能需要更多地关注行业应用方面aspect。
AOP具体实现
AOP是一个概念，并没有设定具体语言的实现，它能克服那些只有单继承特性语言的缺点（如Java），目前AOP具体实现有以下几个项目：
AspectJ (TM)： 创建于Xerox PARC. 有近十年历史，成熟
缺点：过于复杂；破坏封装；需要专门的Java编译器。
动态AOP：使用JDK的动态代理API或字节码Bytecode处理技术。
基于动态代理API的具体项目有：
JBoss 4.0 JBoss 4.0服务器
nanning 这是以中国南宁命名的一个项目，搞不清楚为什么和中国相关？是中国人发起的？
基于字节码的项目有：
aspectwerkz