AOP实现原理:从命令式编程和声明式编程说起
面向方面编程(Aspect Oriented Programming,简称AOP)是一种声明式编程—eclarative Programming)。声明式编程是和命令式编程(Imperative Programming)相对的概念。我们平时使用的编程语言,比如C++、Java、Ruby、Python等,都属命令式编程。命令式编程的意思是,程序员需要一步步写清楚程序需要如何做什么(How to do What)。声明式编程的意思是,程序员不需要一步步告诉程序如何做,只需要告诉程序在哪些地方做什么(Where to do What)。比起命令式编程来,声明式编程是在一个更高的层次上编程。声明式编程语言是更高级的语言。声明式编程通常处理一些总结性、总览性的工作,不适合做顺序相关的细节相关的底层工作。
如果说命……—Domain Specific Language,简称DSL)的概念有相通之处。DSL主要是指一些对应专门领域的高层编程语言,和通用编程语言的概念相对。DSL对应的专门领域—omain)一般比较狭窄,或者对应于某个行业,或者对应于某一类具体应用程序,比如数据库等。
最常见的DSL就是关系数据库的结构化数据查询语言SQL。同时,SQL也是一门声明式语言。SQL只需要告诉数据库,处理符合一定条件的数据,而不需要自己一步步判断每一条数据是否符合条件。SQL的形式一般是 select … where …,update … where …,delete … where …。当然,这样一来,很多基层工作,SQL做不了。因此,大部分数据库都提供了另外的命令式编程语言,用来编写存储过程等,以便处理一些更加细节的工作。
常见的DSL还有规则引擎(Rule Engine)语言、工作流(Workflow)语言等。规则引擎和工作流同时带有命令式编程和声明式编程的特点。规则引擎允许用户按照优先级定义一系列条件组合,并定义对满足条件的数据的处理过程。工作流也大致类似。工作流把最基本的条件判断和循环语句的常见组合,定义为更加高级复杂的常用程序流程逻辑块。用户可以用这些高级流程块组合更加复杂的流程块,从而定义更加复杂的流程跳转条件。用户也可以定义当程序运行上下文满足一定条件的时候,应该做什么样的处理工作。规则引擎和工作流的语言形式有可能是XML格式,也有可能是Ruby、Python、Javascript等脚本格式。我个人比较倾向于脚本格式,因为XML适合表达结构化数据,而不擅长表达逻辑流程。当然,XML格式的好处也是显而易见的。解析器可以很容易分析XML文件的结构,XML定义的条件或者程序流程都可以很方便地作为数据来处理。
介绍了声明式编程和DSL之后,我们来看本章题目表达的内容——AOP。AOP是声明式编程,AOP语言也可以看作是DSL。AOP语言对应的专门领域—omain)就是程序结构的方方面面(Aspect),比如程序的类、方法、成员变量等结构,以及针对这些程序结构的通用工作处理,比如日志管理、权限管理、事务管理等。
AOP处理的工作内容一般都是这样的一些总结性工作:“我想让所有的数据库类都自动进行数据库映射”、“我想打印出所有业务类的工作流程日志”、“我想给所有关键业务方法都加上事务管理功能”、“我想给所有敏感数据处理方法都加上安全管理授权机制”等等。
下面我们介绍AOP的实现原理和使用方法。
AOP实现原理
AOP的实现原理可以看作是Proxy/Decorator设计模式的泛化。我们先来看Proxy模式的简单例子。
MethodInterceptor{ around( method ){ // 做些额外的工作 method.invoke(…); // 调用真正的对象方法 // 做些额外的工作 } }
?
上述的MethodInterceptor就可以分别包装和截获f1()和f2()两个方法。
这里的method参数就是方法对象,在Java、Ruby等面向对象语言中,需要用Reflection获取方法对象。这个方法对象就相当于函数式编程的函数对象。在函数式编程中,函数对象属于“一等公民”,函数对象的获取不需要经过Reflection机制。所以,函数式编程对AOP的支持,比面向对象编程更好。由此我们看到,AOP对应的问题领域确实超出了OOP的力所能及的范围。OOP只能处理同一个类体系内的同一个方法签名的截获和包装工作,一旦涉及到一个类的多个不同方法,或者多个不同类体系的不同方法,OOP就黔驴技穷,无能为力了。
使用Method Reflection的方式截获任何方法对象,是AOP的常用实现手段之一。另一个常见手段就是自动代码生成了。这也回答了前面提出的问题二——如何在应用系统中大规模使用AOP。
Proxy Pattern + Method Reflection + 自动代码生成这样一个三元组合,就是AOP的基本实现原理。Proxy Pattern 和 Method Reflection,前面已经做了阐述,下面我们来讲解自动代码生成。
首先,AOP需要定义一种Aspect描述的DSL。Aspect DSL主要用来描述这样的内容:“用TransactionProxy包装截获business目录下的所有类的公共业务方法”、“ 用SecurityProxy包装截获所有Login/Logout开头的类的所有公共方法”、“用LogProxy包装截获所有文件的所有方法”等等。Aspect DSL的形式有多种多样。有的是一种类似Java的语法,比如AspectJ;有的是XML格式或者各种脚本语言,比如,Spring AOP等。
有了Aspect DSL,AOP处理程序就可以生成代码了。AOP生成代码有三种可能方式:
(1)静态编译时期,源代码生成。为每个符合条件的类方法产生对应的Proxy对象。AspectJ以前就是这种方式。
(2)静态编译时期,处理编译后的字节码。Java、Python之类的虚拟机语言都有一种中间代码(Java的中间代码叫做字节码),AOP处理程序可以分析字节码,并直接产生字节码形式的Proxy。这种方式也叫做静态字节码增强。AspectJ也支持这种方式。Java有一些开源项目,比如 ASM、Cglib等,可以分析并生成Java字节码。这些开源项目不仅可以静态分析增强字节码,还可以在程序运行期动态分析增强字节码。很多AOP项目,比如Spring AOP,都采用ASM/Cglib处理字节码。
(3)动态运行时期,即时处理装载到虚拟机内部的类结构字节码。这也叫做动态增强。比如,Spring AOP。如前所述,Spring AOP使用ASM/Cglib之类的处理字节码的开源项目。Java运行库本身也提供了类似于ASM/Cglib的简单的动态处理字节码的API,叫做 Dynamic Proxy。
以上就是AOP的实现原理:Proxy Pattern + Method Reflection + Aspect DSL + 自动代码生成。
总体来说,实现AOP的便利程度,函数式编程语言 > 动态类型语言 > 静态类型语言。当然,这个不等式并不是绝对的。有些动态类型语言提供了丰富强大的语法特性,实现AOP的便利程度,可能要超过函数式编程语言。
?
原文:http://developer.51cto.com/art/200906/130799.htm