面向方面的编程有什么主要弱点吗？我喜欢通过限制对某个类的调用来减轻横切问题的想法。但对我来说，这有点奇怪。
问题 1. 让我们以 Logger 类为例。每个类/方法可能需要调用 Logger 类的某些方法。将所有这些调用写入 Logger 方面可以使将来的修改变得容易。然而，记录者的面目该由谁来维护呢？如果 Logger 类的开发人员这样做，他/她需要对整个项目有一个全局 View ，我认为如果项目足够大，这是不可能的。另一方面，如果我们允许每个人修改 Logger 的类，就会有太多人访问同一段代码。如果他们中的任何一个犯了错误，代码就会失败。那么，一般来说，谁应该维护这些方面？
问题2.性能会不会有问题？我认为一个切入点就像注册一个事件监听器。如果运行时切入点过多，会不会导致程序变慢？
谢谢
最佳答案
问题1
我认为这很大程度上回答了这个问题:Logger 方面与 Logger 类/实现不同。因此，虽然 Logger 实现可以存在于某些确实执行日志记录任务的独立单元中，但任何日志记录方面都存在于应用程序的域中，并且它们可以在其拦截处推迟工作。因此，责任仅限于应用该方面的实体，这是很有意义的。
问题2
性能对于实现来说是非常具体的，我不知 Prop 体是如何做到的，但是在编译(或有效编译)的情况下猜测，有效地将方面的行为“注入(inject)”到适当的地方(或达到类似目的的事物)，因此对性能的影响将是最小的。
然而，将其纳入解释语言中，您实际上实际上处于“事件监听器”风格的开销中。
弱点
我不是专家，但我会得出一些结论并欢迎补充:
- 缺乏可见性。通过查看目标无法看出哪些方面正在影响它，可能会导致调试困难 - 特别是在影响代码流时。良好的 IDE 支持可能会缓解这个问题。
- 当将方面编译到代码中时，可能会导致更大的二进制文件，尽管我认为这可以忽略不计。
希望这有帮助。
关于programming-languages - 面向方面编程的弱点？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9416752/