AOP@Work: 使用方面的下几个步骤-学习建议之后(8)

管理依赖性

将方面集成到大型多模块系统中时，与工具相关的主要挑战之一就是管理模 块 依赖性。模块 在此指构建单位，比如 Eclipse 项目、Ant 项目和 IntelliJ 模 块。当使用多模块系统开发方面时，需要管理源自方面的新依赖性的创建。 当 一 个模块中的方面织入到另一个模块中定义的类型时，循环构建依赖性很容易发生 。考虑下面这个跟踪系统使用状况的简单计量方面：

aspect MeteringPolicy { 　private int Metered.usage; 　 declare parents: Playable implements Metered; 　after(Metered m) returning: 　　　execution(public * Playable.*(..)) && this (m) { 　　　m.usage++; 　} } public interface Metered { ... }

如果 MeteringPolicy 是不同于 Playable 的模块，则其模块对 Playable 的 模块具有逻辑依赖性。虽然 Playable 的模块对 MeteringPolicy 的模块没有逻 辑依赖性，但需要由其织入（也就是说，它需要与其他模块链接）。通过以逻辑 依赖性的顺序构建模块，然后在稍后的步骤中使用加载时织入或 Ant 中单独的 织 入任务进行织入，一般就可以解决这个问题。在 IDE 中，处理时则比较棘手， 尤 其是当希望能够可视化方面对其他模块的效果时。目前，使用这种跨模块依赖性 来允许可视化的最佳实践是设置附加项目，然后构建一个织入链，如图 5 所示 ：

图 5. 配置多模块系统以可视化方面效果

链接源 模块是使用 Eclipse Linked Source Folder 特性的 AJDT 项目。该 配置创建了一个链接，来自原始项目的所有源文件夹将被织入为构建路径中作为 源的链接文件夹。它还在其 aspectpath 中具有依赖对象模块，它包括原始项目 的所有类路径条目。依赖对象模块依赖于原始模块，而非依赖于链接源模块。在 快速的增量开发过程中，甚至可以关闭链接源模块，并在希望进行可视化时，将 其重新打开。

避免依赖性

当然，对这种依赖性的最好解决方案就是完全避免它们。在简单的情况下， 可 以使用局部化方面，即构建在单个模块中且对其他模块没有作用的方面。更一般 的策略是使用抽象方面（只依赖所发布的接口）和具体方面（对于应用它们的模 块是局部的）。这是 AspectJ in Action 中讨论的 Participant Pattern 的示 例（我喜欢为每个模块配置参与，而不是为每个类配置参与）。

可以尝试将系统中的所有方面聚集到一个模块中，但大多数项目将会很快扩 展 而依赖系统中的许多模块。从而就使管理方面模块与所影响模块之间的逻辑依赖 性成为最大的挑战。通过对比，应该选择将方面放在它们的 “自然” 模块中。 在这个过程中，为了避免对非方面开发人员的影响，应考虑为方面（甚至方面的 注释语法）使用 .aj 文件扩展名。多数 Java 开发工具至少在忽略项目树中的 .aj 文件时不会出现任何问题。使用这种策略，可以只将 Eclipse 项目的本质 从 Java 项目（忽略方面）更改为 AspectJ 项目（包括方面）。有时候，将方面分 离到不同的文件夹中更方便一些。如果需要的话，仍值得尝试在现有模块中为支 持方面的代码使用单独的源代码树，而不是为方面创建单独的模块。此外，保持 方面模块分离并让它们具有逻辑依赖性（正如使用任何其他模块一样）有非常好 的理由。指导原则就是最小化模块之间的耦合并最大化模块内部的内聚。

如果您正面临着包含方面的模块之间存在循环逻辑依赖性，则可以应用 Dependency Inversion Principle，正

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