面向方面编程（AOP）有什么缺点？

6

可怜的工具链支持 - 调试器，分析器等可能不知道的AOP，所以可能好像所有的方面也换成了在代码工作程序代码
代码膨胀 - 小源可能导致更大的目标代码的代码在整个代码库

2009-05-17 21:13:49 Macker

2

我不会把它的关键缺点“编织”，但我见过的最大的问题是开发者经验之一适应能力。并非所有开发人员都了解声明式编程和命令式编程之间的区别。

我们充分利用EntLib 4.1中的policy injection application block以及用于DI的Unity，这对于某些人来说并不是什么沉沦。我发现自己一遍又一遍地向同一个人解释为什么应用程序没有按照他们的期望行事。它通常从他们开始解释某些事情，然后我说“看到这个声明在方法之上”。 :)有些人立刻就明白了，喜欢它，并且变得极富生产力 - 其他人也在奋斗。

学习曲线并不是AOP所特有的，但它似乎有一个更高的学习曲线，表明您的普通开发人员遇到的其他事情。

来源

2009-05-17 21:15:32

7

维护和调试。使用aop，你突然有了在给定点（方法入口，出口，等等）运行的代码，但是在查看代码时，你不知道它甚至被调用，特别是如果aop配置位于另一个文件中，就像xml配置一样。如果建议引起一些变化，那么在调试应用程序时，事情可能会看起来很奇怪，没有任何解释。这不会影响只有新手。

来源

2009-05-17 21:44:44 digitaljoel

+1

http://stackoverflow.com/a/201084/13940 – 2011-12-22 18:00:57

8

我认为最大的缺点就是很好地使用AOP。例如，人们在没有意义的地方使用它，并且不会在任何地方使用它。

例如，工厂模式显然是AOP可以做得更好的东西，因为DI也可以做得更好，但使用AOP时观察者模式更简单，策略模式也更简单。

单元测试会更困难，特别是如果您在运行时进行编织。

如果在运行时进行编织，那么您也会受到性能影响。

当把AOP和类混合在一起时，有一个很好的方法来模拟发生什么事情是一个问题，因为UML我不认为这是一个很好的模型。

除非您使用Eclipse，否则工具确实有问题，但使用Eclipse和AJDT AOP更容易。

我们仍然使用junit和nunit作为例子，所以必须修改我们的代码以允许单元测试在使用特权模式时运行，AOP可以通过测试私有方法来更好地进行单元测试，而且我们不必改变我们的程序只是为了让他们与单元测试一起工作。这是另一个并不真正理解AOP如何有所帮助的例子，我们仍然通过单元测试框架和当前设计模式实现在很多方面与过去相链接，并没有看到AOP如何帮助我们做更好的编码。

来源

2009-05-17 22:04:53

+0

单元测试真的很难吗？单元测试不应该测试这些方面，现在又取决于它们是如何编织的？ – Zombies 2011-10-28 14:18:53

+1

@ Zombies - 你如何测试自己的方面，因为唯一的方法就是包含它们。如果您在运行时编织，那么它必须设置为在测试运行时进行编织。 – 2011-10-28 20:52:42

0

关于维护/调试的论点，面向方面的编程往往与敏捷软件开发实践的所有其他方面并行不悖。

这些做法倾向于从图片中删除调试，用单元测试和测试驱动开发替代它。另外，通过建议维护一个小的，明确的代码足迹比没有建议的大的，难以理解的代码足迹要容易得多（建议是将大的，不可理解的代码足迹转换成小的，清晰的代码足迹）。

来源

2009-05-17 22:12:30 yfeldblum

0

因为AOP的威力，如果你的横切有bug，它可能会导致普遍的问题。另一方面，有人可能会改变程序中的连接点 - 例如，通过重命名或移动方法 - 以方面编写者没有预料到的方式，带来意想不到的后果。模块化横切关注的一个优点是使一个程序员能够轻松地影响整个系统。

来源

2010-11-20 12:12:57 hhafez

8

我认为最大的问题是，没有人知道如何定义一个方面，或的语义如何声明连接点的非程序化。

如果您无法定义某个方面独立于其将嵌入的上下文的独立性，或者定义它所具有的效果，使其不会损害其嵌入的上下文，你（和工具）不能推断它的可靠性。（你会注意到方面最常见的例子是“日志记录”，它被定义为“将一些东西写入应用程序不知道的日志流中”，因为这非常安全）。这违反了David Parnas的关键概念information hiding。我看到的最糟糕的方面之一是将同步原语插入代码;这影响了代码可能具有的可能交互的序列。除非应用程序已经只有微不足道的事情，否则你怎么可能知道这是安全的（不会死锁？不会死锁？不会失效保护？在面对同步合作伙伴抛出的异常时是可恢复的）。

现在通常通过提供某种标识符通配符来定义连接点（例如，“将此方面放入名为”DataBaseAccess *“的任何方法中，为此，编写受影响方法的人员必须发出他们的代码通过以有趣的方式命名代码来实现;这很难模块化，更糟的是，为什么某个方面的受害者甚至必须知道它的存在？并且考虑如果你简单地重命名一些方法会发生什么;方面是否定的需要更长的时间注入，并且你的应用程序中断了，所需要的是连接点规范，它们是有意的;不知何故，该方面必须知道在每个使用点不需要程序员放置霓虹灯标志的情况下需要的地方（AspectJ有一些控制流程相关的连接点，在这个章节中看起来好一点ARD）。

所以方面是一种有趣的想法，但我认为他们在技术上不成熟。而这种不成熟使他们的使用变得脆弱。这就是问题所在。（我是自动化软件工程工具的大爱好者[看我的生物]就是不这样）。

来源

2011-12-22 17:42:37

面向方面编程（AOP）有什么缺点？

回答

相关问题