AOP@Work: 使用AspectJ 5检验库方面 - 编程入门网

尽管如此，大部分库方面至少会将部分规范委托给部署者 —— 以具体类或 目标注释、接口、类型甚至成员命名规范内定义的切入点实现控制。无法在织入 时检查到所有此类情况，因此您必须防御性地编写程序，在必要时放弃一点控制 权，以使部署者可完成其工作。这往往意味着使用模板切入点。与模板方法相似 ，模板切入点是由多个部分组成的，其中某些部分由子方面部署者编写而成，用 于根据手头的程序调整方面。流行的两种模板切入点是 Scope 模式和 Trifecta 模式。

AOP@Work: 使用AspectJ 5检验库方面(13)

模板切入点中的模式

Arnold 表示他已注意到您对 Scope 模式的使用。您的许多简单方面都指定 了库方面中的此类联结点，但允许部署者使用 within 或 withincode 切入点指 定所关注的类型或方法。Buddy 指出没有任何因素阻止子方面用户使用 within (..) 以外的形式，实际上，Arnold 的 volatile 异常就是使用 get(..) 和 set(..) 切入点构成的。您回答说，或许超方面编写者并不希望发生这样的事情 ，但这样做是安全的，因为只会进一步限制 —— 而非扩展核心切入点。

这是一种错误类型，选择错误，但还有其他类型的错误需要密切注意。Zed 问：“若切入点什么也没有选择，又会怎样呢？” 有些通知并非一定要匹配所 有的程序，因此也未必是错误。但很可能是一个无意的疏忽所致，所以编译器会 为通知发出警告。警告是可配置的，用户可忽略警告，若用户知道通知未运行或 不允许运行，也可将其确定为错误。

Holly 指出，缓存方面拥有一个上下文切入点，用于完成运行时类型检查和 变量绑定。您解释说，那实际上是 Trifecta 切入点模式的一部分：

表 7. Trifecta 切入点

组合在一起，如清单 19 所示（caching() 作为核心 切入点）：

清单 20. Trifecta 切入点

/** the pointcut composed from the user, as permitted, with context */ pointcut results() : caching() && permitted() && context();

Trifecta 模式处理了两个问题。首先，如何检查部署者编写了功能超出指定 范围的切入点。为此，库方面编写程序指定了许可的 联结点，并编写一条错误 声明，标识部署者的切入点所选择的任何未经许可的联结点，形式如下：

清单 21. 切入点防卫

/** warn if subaspect pointcut picks out unpermitted join points */ declare warning : caching() && !permitted() : "unpermitted caching()";

其次，Trifecta 模式分离了切入点的可静态确定的 部分，以在错误声明中 使用。这些声明不能接收使用运行时检查的切入点，因为这类切入点在织入时并 非一直可确定。因此，declare error 切入点中不能包含切入点 this(..)、 target(..) 或 args(..)。Trifecta 模式为部署者将它们分开放置在单独的切 入点内，从而使核心切入点可得到独立检查。Trifecta 模式是 “完美” 的， 原因不仅仅在于可将切入点分隔为 3 个部分，而且您可在 3 个地方 —— 部署 者的规范中、警告/错误语句中，以及通知本身中 —— 看到这些部分。

Holly 在她所见过的 Trifecta 切入点中观察到了这些特点，超方面通常将 核心切入点保留为抽象切入点，以强制部署者对其进行定义，但将上下文切入点 定义为空，若部署者不需要上下文切入点，而是在必要时重写它，则可

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!