面向方面编程的弱点？
面向方面的编程有什么重大弱点吗？我喜欢通过限制对某个类的调用来减轻横切问题的想法。但对我来说，这有点奇怪。
问题1.让我们以Logger类为例。每个类/方法可能需要调用 Logger 类的某些方法。将所有这些调用写入 Logger 方面可以使将来的修改变得容易。然而，记录者的面目该由谁来维护呢？如果 Logger 类的开发人员这样做，他/她需要对整个项目有一个全局视图，我认为如果项目足够大，这是不可能的。另一方面，如果我们允许每个人修改 Logger 的类，就会有太多人访问同一段代码。如果他们中的任何一个犯了错误，代码就会失败。那么，一般来说，谁应该维护这些方面呢？
问题2. 性能会不会有问题？我认为一个切入点就像注册一个事件监听器。如果运行时切入点过多，会不会导致程序变慢？
谢谢，
Is there any major weakness for aspect-oriented programming? I like the idea of alleviating crosscutting concerns by limiting the calls towards one class inside its aspect. But to me, it is a little bit weird.
Question 1. Let's take the Logger class example. Every class/method may need to call some method of the Logger class. Writing all those calls inside the Logger aspect makes future modification easy. However, who should maintain the Logger's aspect? If the developer of the Logger class does this, he/she needs to have a global view of the whole project, which I think is kind of impossible if the project is large enough. On the other hand, if we allow everybody to modify the Logger's class, there will be too many people accessing the same piece of code. And if any of them makes a mistake, the code will fail. So, in general, who should maintain the aspects?
Question 2. Will the performance be a problem? I think one pointcut is like registering one event listener. If there are too many pointcut during runtime, will it slow down the program?
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题 1
我认为这很大程度上回答了这个问题：Logger 方面与 Logger 类/实现不同。因此，虽然 Logger 实现可以存在于某些确实执行日志记录任务的独立单元中，但任何日志记录方面都存在于应用程序的域中，并且它们可以在其拦截处推迟工作。因此，责任局限于应用该方面的实体，这是很有意义的。
问题 2
也许感兴趣。
性能对于实现来说是非常具体的，我不知道具体是如何做到的，但是在编译（或有效编译）的情况下猜测，将方面的行为有效地“注入”到适当的位置并不是不可行的（或达到类似目的的事情），因此对性能的影响将是最小的。
然而，将其引入解释语言中，您实际上实际上处于“事件侦听器”风格的开销中。
弱点
我不是专家，但我会得出一些结论并欢迎大家补充：
希望这有帮助。
Question 1
I think this largely answers the question: the Logger aspect is not the same as the Logger class/implementation. So whilst the Logger implementation can exist in some standalone unit which indeed performs the task of logging, any logging aspect(s) exist within your application's domain and they can defer the work at their intercepts. The responsibility is therefore localised to the entities for which the aspect is being applied, which makes good sense.
Question 2
Perhaps of interest.
Performance will be very specific to implementation, and I don't know in detail how anyone does it, but at a guess in a compiled (or effectively compiled) situation it would not infeasible to effectively 'inject' the aspect's behaviour into the appropriate places (or things to achieve a similar end) and as such the performance hit would be minimal.
Take this into interpretted languages however, and you are effectively indeed in the 'event listener' style of overhead.
Weaknesses
I'm no expert, but I'll draw a couple of conclusions and invite any additions:
Hope this helps.