AOP 面向方编程(Aspect Oriented Programming)

在程序员的圈子里面,有一群人数很少但态度却十分坚定的开发人员。当他们宣称，真正的程序员会编写自己的驱动程序。

因为如果不这样，那么采用任何其他的方式都将会是疯狂和缺乏技术理性的，并且还会承担一些不必要的风险。 
 

在软件行业的另一端，人们却在为类似于面向方面编程（Aspect Oriented Programming即AOP）的技术欢呼雀跃。他们以非常严肃的态度说道，真正的程序员希望尽可能的保持多产，这样才能稳住自己的饭碗。相对于对自己工作方式三天两头的革新，这些程序员们更希望能开发更多的程序和更为有效的对代码进行重用。

AOP是从什么地方来的？

多年以来，面向对象（OO）时编程技术革新的先锋，但是，即使是针对不同功能编写分离代码片段的面向对象思想也无法将程序开发人员从一遍遍重写应用程序多个部分的烦恼中解脱出来。来自Xerox Palo Alto Research Lab（即PARC）的研究人员早在1990年开始就对面向对象思想的局限性进行了分析。他们研究出了一种新的编程思想，借助这一思想或许可以通过减少代码重复模块从而帮助开发人员提高工作效率。与此同时，美国Northeastern University的博士生Cristina Lopes和其同事也开始了类似的思考。最终，美国国防先进技术研究计划署（Defense Advanced Research Projects Agency即DARPA）注意到了这项工作，并提供了科研经费，鼓励将二者的工作成果结合起来。由此，AspectJ诞生了。它作为Java语言的一套扩展系统使得当今的程序员们现在就可以体验AOP的思想。 Avanade公司的高级方案构架师Adam Magee认为，AOP的核心思想就是“将应用程序中的商业逻辑同对其提供支持的通用服务进行分离。”该公司是一架专注于微软技术的集成商。 AOP的创业者们把这些通用服务称之为“横切关注点（crosscutting concerns）”，因为这些服务所提供的功能将横贯应用程序的多个对象需求。将AOP应用到多个项目中的Magee也认为，“开发人员可以对横切关注点进行检测、审计、登陆、安全性检查或异常处理。编写这些服务的接口代码将会非常耗费时间，并且开发人员要学会如何这样做本身就已很长时间。”“这些事情将开发人员的精力从解决企业问题上面转移开来——而后者才是价值之所在。这些麻烦将他们引到了钻研复杂操作系统的艰难道路上。

优势

AOP的目标就是要避免这些问题。它将编写横切关注点代码的工作进行分离——也就是所谓的“方面（aspects）”——把他们从组织为商业逻辑的对象的编写工作中分离出来，然后提供相应的功能构架。这样一来，应用程序就可以使用各个方面所提供的功能而无需重新编译或重新编写任何代码。

在一个应用程序有很多对象都需要相同横切关注点，这一技术即着眼于通过帮助开发人员创建所需要的横切关注点定义来为开发人员节省时间。如果要对每一个对象编写一个登录系统——AOP中所谓的“散射（scattering）”实践——AOP的先行者们建议在项目的设计阶段，开发人员就应当定义应用程序中每个对象的登录需求，然后创建一个单独的登录工具执行该应用程序中任何所需的登录操作。 AOP的支持者们认为，这样的方式有几个优点。第一，在定义应用程序对某种服务（例如登录）的所有需求的时候，所花费的精力将使得该服务能够被更好的定义，更好的被编写代码，并获得更多的功能。这种方式还能够处理在代码涉及到多个功能的时候所出现的问题，例如改变某一个功能可能会影响到其它的功能，在AOP中把这样的麻烦称之为“纠结（tangling）”。

其次，在创建离散方面所进行的分析将有助于为开发团队指定一位精于该项工作的专家，由此负责这项工作的最佳人选将可以有效利用自己的相关技能和经验。第三个好处则是持久性的。标准的以对象为导向的项目开发中，不同的开发人员通常会为某项服务编写相同的代码，例如登录。随后他们会在自己的实施中进开发各自的登录服务以满足不同单个对象的需求。而通过创建一段单独的代码片段，AOP提供了解决这一问题的持久简单的方案，这一方案强调了未来功能的重用性和易维护性：不需要在整个应用程序中一遍遍重新编写登录代码，AOP使得仅仅编写登录方面（logging aspect）成为可能，并且可以在这之上为整个应用程序提供新的功能。所有的这些好处都是的需要编写的代码量大大缩减，由此节省了时间，控制了开发成本，并且能将资源投入到比编写登录程序更为有价值的活动中去。
 

AOP的工作原理

IBM的客户经理Brad Kasell说道：“传统上当你开始开发应用程序的时候，你从定义商业功能开始入手，即哪些应用程序需要完成的所有功能。”

“但总是项目涉及的所有开发人员都没有编写规范，因此开发人员们最终将会发现一个应用程序在不同的地方需要不同类型的登录服务，因此需要在不同的时候一遍遍的编写他们。”“AOP则意味开发人员最终能够获得这样的机会，即提出一个问题：‘如何才能使得你只需编写一次就可以让这段代码服务于整个应用程序？’” 因此，AOP项目的起点在于开发人员确认所有对象都会需要的功能。随着对象的进一步开发，开发人员将能够找出每个对象都需要的一个普遍的功能，即“横切点”。这时，不同于在对象内部编写登录服务，开发人员将编写一个“切点（point cut）”，这一“切点”将“织入（weaves）”到对象的方面（aspect）中。这样的方式时的应用程序将有一些对象和一个单独的代码池所组成，在对象调用所需的服务视，这一代码池将提供通用的服务。

如何进行编程

要把AOP引入到工作中来是比较简单的，现在市面上已经有了很多种工具。在这一领域，开放源代码软件是主打。最初由PARC设计的AspectJ在2002年已经被转手给Eclipse Foundation，它现在是最为流行的AOP工具。 AspectJ将其自身标榜为“同Java编程语言无缝集成的面向方面扩展”，它提供了新的语法来定义、创建和使用方面。AspectJ可以被引入到多个编程工具中。最为常见的AOP工具是AspectWerkz，这是两位BEA员工所开发的，这一软件在松散的GNU公共许可证下发布。

2005年1月，AspectJ和AspectWerkz达成协议，同意将二者的成果综合到一起，取其精华创建一个单一的工具。像Jboss这样的商用软件制造商同样提供AOP产品。这一企业所开发的JBoss AOP已经在2004年晚期发布，同样提供了面向方面的框架和一个方面库。在.NET的阵营中，事情的进展则要缓慢一些。2005年1月，微软发布的Enterprise Library提供了7种不同的“应用程序块（

application blocks）”。Avanade的Magee认为这些组件可以被认为是就方面，使用Visual Studio .Net. Loom中的属性进行访问则是另一个回事。但这些工具所采用的方法决不是统一的。AspectJ是对Java的扩展。反对阵营认为，对语言进行扩展存在与之俱来的麻烦，AOP应当通过使用XML元数据来进行部署，从而定义横切点和所调用的对象。开发工具以及什么地方可以找到这些工具。

有限制条件么？

这些方法上的不一致和实际应用情况使得没有主流IDE制造商将AOP作为产品工具中的“正式”部分。这也让很多人感觉到尽管AOP的核心思想非常有用，但它仍然没有成熟。“我相信AOP还不足以打入主流编程领域，因此很多人并不能确定如何才能将这一技术引入到日常的工作中去，” BEA技术办公室的技术经理Michael Smith说道。“这是在主流和技术前沿之间的一块中间地带。” 这一理念正存在于这一中间地带中，其真正的潜能在某种程度上仍然是未知的。开发顾问ThoughtWorks的咨询师John Tirsen表示，它已经在多个项目中使用了AOP。但模块化服务（modularising

services）的思想并非是全新的。“以前就有CORBA拦截机做过这样的事情”，他说道。“更具争议的问题在于它是否能够用到横切商业逻辑（cross-cutting business logic）上去。”

BEA的Smith同样认可这一未被触及的潜力。“沿着技术发展的道路我们可以认为或许你希望借助AOP来对中间件的运行方式进行调整，或许希望根据不同的商业规则在不同时间为不同的功能创建中间件层。尽管这种类型的工作听起来很刺激，但没有人能够为这一技术的发布实施和广泛采用提出一份时间表。 AOP的精灵正跃跃欲试，即将从瓶子里面跑出来。

“6个月以前，没有人问我AOP，”Smith说道。“现在你可以在AOP讨论会之中看到听众在我甚至没有提到这一技术的情况下问到这一问题。无论你是否希望编写自己的设备驱动程序，这都是一个明显的信号，即AOP在将来的一段时间中值得人们去研究。

转http://kekesoft.spaces.live.com/blog/