【发布时间】：2010-10-26 21:45:19
【问题描述】：
面向切面编程有哪些可能和严重的缺点？
例如：新手的隐秘调试（可读性影响）
【问题讨论】：
标签： aop
【发布时间】：2010-10-26 21:45:19
【问题描述】：
我认为最大的问题是没有人知道如何定义一个方面的语义，或者如何非程序地声明连接点。
如果您无法独立于将要嵌入的上下文来定义方面的作用，或者无法以不损害其嵌入的上下文的方式定义它的效果，您（和工具）无法推断它可靠地做什么。 （您会注意到方面最常见的示例是“日志记录”，它被定义为“将一些内容写入应用程序不知道的日志流”，因为这是非常安全的）。这违反了 David Parnas 的 information hiding 的关键概念。我看到的最糟糕的方面示例之一是将同步原语插入代码的方面。这会影响代码可能具有的交互顺序。你怎么可能知道这是安全的（不会死锁？不会活锁？不会无法保护？面对同步伙伴中抛出的异常可以恢复？）除非应用程序已经只做了一些琐碎的事情。
现在通常通过提供某种标识符通配符来定义连接点（例如，“将此方面放入任何名为“DataBaseAccess*”的方法中。为此，编写受影响方法的人必须表明他们的意图。通过以有趣的方式命名他们的代码来对代码进行切面化；这几乎不是模块化的。更糟糕的是，为什么切面的受害者甚至必须知道它存在？考虑一下如果你只是重命名一些方法会发生什么；切面不再是在需要的地方注入，你的应用程序就会中断。需要的是 有意 的连接点规范；不知何故，切面必须知道在哪里需要它，而程序员在每次使用时都放置霓虹灯点。（AspectJ 有一些与控制流相关的连接点，在这方面似乎更好一些）。
所以方面是一种有趣的想法，但我认为它们在技术上不成熟。这种不成熟使它们的使用变得脆弱。这就是问题所在。 （我是自动化软件工程工具的忠实粉丝 [查看我的简历]，但不是这样）。
【讨论】：
-
+1，方法名的字符串匹配是一种极其可怕（脆弱）的注入切入点的方式。
由于 AOP 的强大功能，如果您的横切存在错误，可能会导致广泛的问题。另一方面，有人可能会以方面编写者没有预料到的方式更改程序中的连接点（例如，通过重命名或移动方法），从而产生意想不到的后果。模块化横切关注点的一个优点是使一名程序员能够轻松地影响整个系统。
【讨论】：
关于维护/调试论点，面向方面的编程倾向于与敏捷软件开发实践的所有其他方面齐头并进。
这些做法倾向于从图片中删除调试，取而代之的是单元测试和测试驱动的开发。
此外，与没有建议的大而难以理解的代码足迹相比，维护一个带有建议的小而清晰的代码足迹可能要容易得多（建议是将一个大的、难以理解的代码足迹转换为一个小的、清晰的代码足迹）。
【讨论】：
我认为最大的缺点是很好地使用 AOP。例如，人们在它没有意义的地方使用它，并且不会在它有用的地方使用它。
例如，工厂模式显然是AOP可以做得更好的东西，因为DI也可以做得很好，但是观察者模式在使用AOP时更简单，策略模式也是如此。
单元测试会更难，尤其是如果你在运行时进行编织。
如果在运行时编织，那么您也会受到性能影响。
在将 AOP 与类混合时，有一个很好的方法来模拟正在发生的事情是一个问题，因为我认为 UML 在那个时候不是一个好的模型。
除非您使用 Eclipse，否则工具确实会出现问题，但是，使用 Eclipse 和 AJDT AOP 会容易得多。
例如，我们仍然使用 junit 和 nunit，因此必须修改我们的代码以允许单元测试运行，当使用特权模式时，AOP 也可以通过测试私有方法来进行更好的单元测试，我们不必更改我们的程序只是为了让它们与单元测试一起工作。这是另一个没有真正理解 AOP 如何提供帮助的例子，我们仍然在许多方面与单元测试框架和当前的设计模式实现联系在一起，并且看不到 AOP 如何帮助我们更好地编码。
【讨论】：
-
单元测试真的很难吗？单元测试不应该测试方面，现在与它们的编织方式无关吗？
-
@Zombies - 你如何自己测试这些方面，因为这样做的唯一方法是包含它们。如果您在运行时编织，则必须将其设置为在测试运行时进行编织。
-
一个新手的谦虚问题：什么工厂模式具有横切关注点？我的意思是，为什么 AOP 做得更好？
-
AspectJ 不仅仅用于横切关注点。您可能会发现这篇文章很有用，例如，关于 AspectJ 和设计模式：homepages.cwi.nl/~storm/teaching/reader/HannemannKiczales02.pdf
维护和调试。使用 aop，您突然有了在给定点运行的代码（方法入口、退出等），但仅查看代码，您甚至不知道它是否被调用，特别是如果 aop 配置在另一个文件中，如 xml 配置。如果建议引起了一些变化，那么在调试应用程序时，事情可能看起来很奇怪，没有任何解释。这不仅仅影响新手。
【讨论】：
我不会称其为严重劣势，但我看到的最大问题是开发人员的经验和适应能力。并非所有开发人员都了解声明式编程和命令式编程之间的区别。
我们在 EntLib 4.1 中广泛使用 policy injection application block 以及在 DI 中使用 Unity，这对某些人来说并不是很快就会接受的东西。我发现自己一遍又一遍地向同样的人解释为什么应用程序没有按照他们期望的方式运行。它通常开始他们解释一些东西，我说“看到方法上方的声明”。 :) 有些人马上就得到它，喜欢它并变得非常高效——其他人则在苦苦挣扎。
学习曲线并不是 AOP 独有的，但它似乎比普通开发人员遇到的其他事情具有更高的学习曲线。
【讨论】：
- 较差的工具链支持 - 调试器、分析器等可能不了解 AOP，因此可能在代码上工作，就好像所有方面都已被过程代码替换了一样
- 代码膨胀 - 小源代码可能导致更大的目标代码，因为代码在整个代码库中“编织”
【讨论】：