AOP@Work: AOP工具比较，第2部分-开发环境 - 编程入门网
| 因为编译器能够立即指出这类错误。 如果没有进行静态检查，那么这类错误到了运行的时候才会被捕获。AspectJ 对 于所有的方面声明都有完整的静态检查，所以 AspectJ 编译器会立即指出切入点 中拼写错误的引用。其他 AOP 工具可以检查方面声明的合格程度，但是，不管是 用注释还是用 XML 声明，它们都没有提供切入点的静态检查。对于典型的 Java 开发人员来说，这样做的后果是要投入大量精力查看 XML 值，而且还会在运行时 带来大量调试错误。如果切入点中放错一个括号，那么不会显示容易修改的编译 错误，只会造成很难阅读和调试的运行时堆栈跟踪。
有了 AspectJ 编译 器，方面代码就可以得到 Java 代码从静态检查得到的全部好处。如果没有该编 译器，那么在键入切入点表达式时，必须非常小心，而且还要适应通过执行应用 程序找出错误，因为切入点的表达式非常复杂，所以这很容易带来问题。 在图 1 中可以看到两种工具处理切入点中括号错误的区别。图的上面显示了 AspectJ 中错误的出现方式，图的下面显示了 AspectWerkz 中错误的出现方式。 图 1. 在 AspectJ 中和在 AspectWerkz 中定位语法错误的比较
AspectJ 的编译器在键入代码的时候就会主动解析方面代码，立即指出括号错 误。使用 AspectWerkz，则要到运行时才会检查出这个错误。由此可以看到，在 没有切入点静态检查的工具中，这类语法错误需要更多时间调试。但是，更常见 、更费时的问题则是因为在切入点中拼写出错误类型名这类的错误造成的。在没 有进行静态检查的情况下，AOP 框架无法调用任何通知，因此会悄无声息地失败 。指出错误在哪特别费时，尤其在初次接触 AOP 和切入点时。有了静态检查， AspectJ 的编译器会发出警告，指出无法解析的类型名称或签名。正如在后面讨 论的那样，在即将发布的工具中，可以期盼获得静态检查支持方面的提高。 AOP@Work: AOP工具比较，第2部分-开发环境(3)时间:2011-09-04 IBM Mik Kersten未来构建环境的考虑 AOP 工具的方面声明的简洁性，应当有助于判断该工具静态检查的优势。例如 ，Spring AOP 创建通知时要进行大量 XML 的搭配。某种工具要求的手工搭配越 多，花在编写和调试这个搭配的时间就会越多，尤其在有许多方面的时候。从积 极的方面来看，可以通过自动生成 XML 搭配来解决这个问题。稍后将讨论 JBoss AOP 的 Eclipse 插件，它能够做到这一点。 如果选择了 AspectJ 作为 AOP 工具，那么所有需要使用方面的 Java 项目都 必须使用 AspectJ 的编译器。对于某些项目来说，这可能存在问题（例如在集中 指定生产构建使用的编译器的情况下）。从积极方面来说，AspectJ 编译器打算 替代 Java 编译器。另一个有关的考虑是：每种工具因为添加对方面的支持而带 来的编译开销各不相同。下一节将详细讨论这一点。最后，还应当记住 AspectJ 的语言扩展方法要求项目中使用的所有与构建有关的工具都要扩展到 AspectJ。 这意味着许多现成的解析 Java 代码的工具无法用于 AspectJ 代码（例如，基准 和报告工具，依赖性和风格检查器，以及版本控制使用的 diff 工具）。 语言扩展在构建集成上的利弊 这一节将从构建集成的角度描绘 AspectJ 的语言扩展方法的一些主要利弊： - 使用普通 Java 源代码的工具必须扩展才能用来处理方面代码。 - 需要使用不同的编译器。 + 扩展的 Java 编译器提供了全部方面代码的完整静态检测。 + 编写和调试切入点变得更加容易。 虽然语言扩展方法生来就有不足，但是它的一些优点将来也可以应用到注释和 XML 风格上。把这些优点提供给注释风格，正是 AspectJ 和 AspectWerkz 两个 团队联合进行 @Aspect 开发工作的主要动机，而且这还表明，如果使用底层的 AOP 编译器，那么静态检查也能用于注释风 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
