面向编程（AOP）？
面向方面编程有哪些可能的和关键的缺点？
例如：新手的神秘调试（可读性影响）
我认为最大的缺点是很好地使用AOP。 例如，人们在没有意义的地方使用它，并且不会在任何地方使用它。
例如，工厂模式显然是AOP可以做得更好的东西，因为DI也可以做得更好，但使用AOP时观察者模式更简单，策略模式也更简单。
单元测试会更困难，特别是如果你在运行时进行编织。
如果在运行时编织，那么你也会受到性能影响。
在将AOP与类混合时，有一个很好的方法来模拟发生的事情是一个问题，因为UML我认为这不是一个好的模型。
除非您使用Eclipse，否则工具确实有问题，但使用Eclipse和AJDT AOP更容易。
我们仍然使用junit和nunit作为例子，所以必须修改我们的代码以允许单元测试运行，当使用特权模式时AOP也可以通过测试私有方法来进行更好的单元测试，而且我们不必改变我们的程序使他们与单元测试一起工作。 这是另一个并不真正理解AOP如何有所帮助的例子，我们仍然通过单元测试框架和当前设计模式实现在很多方面与过去相链接，并没有看到AOP如何帮助我们做更好的编码。
我认为最大的问题是没有人知道如何定义某个方面的语义，或者如何非程序地声明连接点。
如果你不能定义一个方面独立于它所嵌入的上下文的行为，或者定义它所具有的效果，以至于它不会损害它所嵌入的上下文，那么你（和工具）不能推断它的可靠性。 （你会注意到方面最常见的例子是“日志记录”，它被定义为“将一些东西写入应用程序不知道的日志流中”，因为这非常安全）。 这违反了David Parnas关键信息隐藏的概念。 我看到的最糟糕的方面之一是将同步原语插入代码; 这影响了代码可能具有的可能交互的序列。 除非应用程序已经只有微不足道的事情，否则你怎么可能知道这是安全的（不会死锁？不会死锁？不会失效保护？在面对同步合作伙伴抛出的异常时是可恢复的）。
现在，通常通过提供某种标识符通配符来定义连接点（例如，“将此方面放入名为”DataBaseAccess *“的任何方法中。为此，编写受影响方法的人员必须表示其代码的意图是通过以有趣的方式命名它们的代码来进行区分;这很难模块化，更糟糕的是，为什么某个方面的受害者甚至必须知道它的存在？并且考虑如果你简单地重命名某些方法会发生什么;该方面不再被注入需要的是，你的应用程序中断了，需要的是有意识的连接点规范;不知何故，该方面必须知道在哪里需要它，而不需要程序员在每个使用点放置一个霓虹灯（AspectJ有一些控制流相关在这方面看起来好一些点）。
所以方面是一个有趣的想法，但我认为他们在技术上不成熟。 而这种不成熟使他们的使用变得脆弱。 这就是问题所在。 （我是自动化软件工程工具的一个忠实粉丝（看我的生物）就是不这样）。
链接地址: http://www.djcxy.com/p/95165.html