面向方面编程(AOP)有哪些缺点？

Question

面向方面编程有哪些可能的和关键的缺点？

例如:新手的神秘调试(可读性影响)

Answer 1

我认为最大的问题是没有人知道如何定义方面的语义,或者如何非程序地声明连接点.

如果你不能独立于嵌入的上下文定义一个方面的作用,或者定义它所具有的效果,使其不会破坏嵌入它的上下文,那么你(和工具) )无法推断它的可靠性.(你会注意到方面最常见的例子是"logging",它被定义为"将一些东西写入应用程序不知道的日志流",因为这是非常安全的).这违反了David Parnas关于信息隐藏的关键概念.我看到的最糟糕的方面之一是将同步原语插入代码中; 这会影响代码可能具有的交互顺序.你怎么可能知道这是安全的(不会死锁？不会活锁？不会失败保护？面对同步伙伴中抛出的异常可以恢复？)除非应用程序只做了一些微不足道的事情.

现在通常通过提供某种标识符通配符来定义连接点(例如,"将此方面放入名为"DataBaseAccess*"的任何方法中.为此,编写受影响方法的人必须表明其代码的意图是通过以有趣的方式命名他们的代码来指定;这几乎不是模块化的.更糟糕的是,为什么一个方面的受害者甚至必须知道它存在？并考虑如果你只是重命名一些方法会发生什么;方面不再注入它的位置需要,你的应用程序中断了.需要的是有意的连接点规范;不知何故,方面必须知道在不需要程序员在每个使用点放置霓虹灯标志的地方.(AspectJ有一些控制流相关加入在这方面看起来好一些的点).

因此,方面是一种有趣的想法,但我认为它们在技术上是不成熟的.而这种不成熟使他们的使用变得脆弱.这就是问题所在.(我是自动化软件工程工具的忠实粉丝[请参阅我的简历],不是这样).

Answer 2

• 糟糕的工具链支持 - 调试器,分析器等可能不知道AOP,因此可能会对代码起作用,就像所有方面都被过程代码替换一样
• 代码膨胀 - 小代码可以导致更大的目标代码,因为代码在整个代码库中被"编织"

Answer 3

我认为最大的缺点是使用AOP.例如,人们在没有意义的地方使用它,并且不会在它所使用的地方使用它.

例如,工厂模式显然是AOP可以做得更好的事情,因为DI也可以做得很好,但是使用AOP时观察者模式更简单,战略模式也是如此.

单元测试会更难,尤其是如果你在运行时进行编织.

如果在运行时编织,那么您也会受到性能影响.

在将AOP与类混合时,有一个很好的方法来模拟正在发生的事情是一个问题,因为UML我不认为那时是一个很好的模型.

除非你使用Eclipse,否则工具确实存在问题,但是,使用Eclipse和AJDT AOP要容易得多.

我们仍然使用junit和nunit,因此必须修改我们的代码以允许单元测试运行,当使用特权模式时,AOP也可以通过测试私有方法来做更好的单元测试,而我们不必更改我们的程序使它们与单元测试一起工作.这是另一个没有真正理解AOP如何有用的例子,我们仍然通过单元测试框架和当前设计模式实现以多种方式链接到过去,并且没有看到AOP如何帮助我们做更好的编码.

Answer 4

维护和调试.使用aop,你突然拥有在给定点运行的代码(方法入口,退出,无论如何),但只是查看代码,你不知道它甚至被调用,特别是如果aop配置在另一个文件中,像xml配置.如果建议导致一些更改,那么在调试应用程序时,事情可能看起来很奇怪,没有任何解释.这不仅仅影响新手.