AOP@Work: AOP和元数据：完美的匹配，第2部分-用元数据实现多维接口

AOP@Work: AOP和元数据：完美的匹配，第2部分-用元数据实现多维接口2011-09-04 IBM Ramnivas Laddad简介：在这篇由两部分组成的关于组合使用元数据和 AOP 的系列文章的第二部分中，作者及 AOP 实践者 Ramnivas Laddad 将推荐一种把元数据视为多维关注点空间中的签名的全新方法。他还将介绍有效组合使用元数据与 AOP 的一组准则，并讨论元数据注释将如何影响面向方面的编程的应用。

在本文的第一部分中，我介绍了新的 Java 元数据功能，并说明了如何以及在什么地方可以用元数据注释最有效地增强 AOP 的连接点模型。我还概括三种最重要 AOP 系统对元数据的已有支持，这三种系统是：AspectWerkz、AspectJ 和 JBoss AOP。在第一部分中，还介绍了元数据对 AOP 系统的模块性的影响，最后，还重新构建了一个例子，以说明如何在 AOP 系统中逐步添加元数据注释。

在本文的第二部分中，我将介绍一种全新的方法，该方法将元数据看成通往多维签名空间的一种途径。这种方法具有分解元素签名的实际用途，并且在总体上对设计注释类型很有用，甚至对于那些不从事 AOP 的开发人员也很有帮助。在本文的第二部分中，我仍然将重点讨论元数据方法在面向对象的编程中的最有效用法。其中，我将展示一种用 AOP 有效减少使用元数据注释所带来的模块性损失的用法。在本文的最后，我将提供一组确定什么时候以及如何最佳利用元数据的准则。我还会考虑添加元数据对采用 AOP 的影响。

主导签名的专制

程序元素的签名，如类型、方法或者由几个组件组成的字段，这些组件包括元素名、访问规范、基本类型、方法参数、异常规则等。并不是每种程序元素都要使用所有组件，但是不管在什么情况下，程序元素的名字是最有价值的东西，特别是当它对外公开时，因为它会通知其使用者该元素的作用。

如果不使用元数据编程，那么每个程序元素只能使用一个名字。在这种情况下，常见的作法是将程序元素按它们的主要或者首要功能命名。例如，请看下面 credit 方法的签名：

public void credit（float amount）;

这个方法名只反映了方法的一个属性：执行信贷业务的业务逻辑。该元素的所有其他功能都丢失了。虽然这种签名可以告诉使用这个方法的客户该元素的主要功能，但是它无法通知其他客户 —— 那些实现横切关注点的客户，比如安全和事件管理客户。这就是主导签名的专制，由只使用一个名称来表示元素的限制所导致的。

在 AOP 研究文献中经常会讨论到类似的情况：主要分解（decomposition）的专制，其中主要的关注点（通常是业务逻辑）支配了类的设计，特别是继承层次（inheritance hierarchy）。

签名纠结

确保元素的签名与其横切功能匹配的一种方法是修改签名的名称，使它反映所有功能。例如，还需要在某个事务中运行并获得认证的信贷业务可以具有以下签名：

public void transactional_authorized_credit（float amount）;

在看到像上面的这样的名字时，确实能让您想到方法的横切事务和认证要求，但是这会使代码变得很糟糕，只有很少的开发人员会使用它。事实上，只有在特殊环境中才会看到这种名字，比如使用特殊的命名约定将方法标识为内部消费。

随着系统的发展，上面的方法还会带来一个严重的问题。如果程序元素的横切特性发生改变，那么它的名字和它的所有引用者都需要做相应的改变。例如，如果在上面的例子中，系统的发展使得信贷业务不再需要认证，那么这个方法名就需要改为 transactional_credit（），而这个方法的所有调用都要做相应的改变。

这种方法的另一个问题是组合使用来自多关注点的元素的名称增加了调用者的识别负担。例如，上述方法的业务调用者对该方法的其他特性并不感兴趣，但是仍然要受其他关注点的影响。

如果熟悉 AOP，那么您已经知道代码纠结 —— 将多关注点代码混合到一个模块中 —— 会导致难于理解和难于维护的代码。签名纠结与此类似。就像在上面的例子中，当程序元素的名字反映其在多个关注点中的作用时，我们就称之为纠结的签名。