面向方面编程有哪些可能的和关键的缺点？
例如：新手的神秘调试（可读性影响）
我认为最大的问题是没人知道如何定义切面的语义, or 如何非程序地声明连接点.
如果您无法独立于要嵌入的上下文来定义某个方面的功能，或者无法以不损害其嵌入的上下文的方式定义它所具有的效果，那么您（和工具） ）无法可靠地推断出它的作用。 （您会注意到方面最常见的示例是“日志记录”，它被定义为“将一些内容写入应用程序不知道的日志流”，因为这是非常安全的）。这违反了大卫帕纳斯的关键概念信息隐藏 http://en.wikipedia.org/wiki/Information_hiding。我看到的最糟糕的方面示例之一是将同步原语插入到代码中；这会影响代码可能具有的交互顺序。您怎么可能知道这是安全的（不会死锁？不会活锁？不会无法保护？在同步伙伴中抛出异常时可以恢复？）除非应用程序已经只做了一些琐碎的事情。
连接点现在通常通过提供某种标识符通配符来定义（例如，“将此方面放入任何名为“DataBaseAccess*”的方法中）。为了实现这一点，编写受影响方法的人员必须表明其代码的意图通过以有趣的方式命名代码来进行方面化；这几乎不是模块化的。更糟糕的是，为什么方面的受害者甚至必须知道它的存在？并考虑如果您简单地重命名某些方法会发生什么；方面不再注入它所在的位置是需要的，并且你的应用程序会中断。需要的是连接点规范，它是故意的;无论如何，方面必须知道哪里需要它，而不需要程序员在每个使用点放置霓虹灯标志。 （AspectJ 有一些与控制流相关的连接点，在这方面似乎更好一些）。
因此，方面是一种有趣的想法，但我认为它们在技术上还不成熟。这种不成熟使得它们的使用变得脆弱。这就是问题所在。
（我是自动化软件工程工具的忠实粉丝[参见我的简历]，但不是这样的）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
