我是AOP领域的新手。我第一次编写应用 AOP 概念的代码时,我很高兴了解方面如何消除应用程序中的横切模式。应用 AOP 解决诸如安全、日志记录、事务、审计等横切模式的想法让我不知所措。
然而,当我第一次向我工作的客户提议使用 AOP 时,我被告知他们不支持它。有人告诉我,AOP 意味着更多的维护!如果您的代码更改,您的切入点必须更改。因此,每当您更改应用它们的代码时,您可能必须分析、更改和测试您的方面?
对此你有什么想说的?为什么主流公司还没有对 AOP 的广泛使用开放?AOP 世界将走向何方?
6 回答
AOP 是一个相对较新的概念,大公司普遍对新概念持谨慎态度。他们害怕被大量的 AOP 代码卡住而找不到可以维护它的人。
关于具体的批评,似乎不知情或被误解。AOP 的全部意义在于通过减少横切关注领域的代码重复来减少维护工作。但是,确实,它会使代码更难理解,从而使维护变得更加困难——使用 AOP,当您查看特定的代码段时,总是有可能在其他地方定义的方面完全改变其行为。
就个人而言,我不确定 AOP 的好处(真的有那么多横切关注点吗?)是否超过了这个问题。我能看到解决它的唯一方法是通过 IDE 的支持;但是让你更加依赖 IDE 也不是一件好事。
趋势似乎是应用服务器和框架以与 AOP(即中央声明性定义)类似的方式解决特定的、重要的横切关注点(如事务和安全性),但没有赋予您混淆维护开发人员的全部权力。
AOP 是其中一个有趣的想法,但在实践中并不能很好地工作。Java 使用 AOP 已有十年或更长时间了,但它并没有被太多使用,因为它似乎引入的问题多于它所修复的问题。
有人告诉我,AOP 意味着更多的维护!
这很愚蠢,而且完全错误。AOP 是一种必不可少的工具,可以让您从代码中消除噪音,并让您将精力集中在交付业务价值上。当业务规则发生变化时,您不必费力地通过数英里的框架逻辑来反映代码中的新变化。
像任何工具一样,您必须确保正确使用它。我不得不解决这样一个事实,即我的 AOP 日志记录会无意中记录解密的信用卡:
http://www.agileatwork.com/what-happens-when-you-actually-use-aop-for-logging/
我必须对应用程序进行一些性能优化,然后我选择在 AspectJ 中编写自定义分析器。起初我对使用 AOP 持怀疑态度,但我意识到它绝对是完成这项工作的完美工具。
但是,有很多工作我不会使用它。对于可能影响应用程序功能的任何事情,我都会非常谨慎。额外的间接层和缺乏透明度会给尝试添加功能或修复错误的开发人员带来太多问题。
人们忘记了 Java 注释及其在 Guice 和 Spring 等框架中的使用受到 AOP 的启发。我会说 Java 注释是 AOP 今天的发展方向。
我们使用 AspectJ AOP 实现并且对它非常满意。您应该将它视为工具包的另一部分,它使一些概念比“普通”java 更容易表达。我们目前主要使用它来为我们的服务提供 JMX 接口。
确实应该有更多的 IDE 支持它(我在看你的 JetBrains!),这肯定会有助于采用。