面向方面编程（AOP）如何影响代码质量？
面向方面编程（AOP）似乎是一个有趣的概念。起初我对此非常热情，但当我阅读更多内容并看到人们描述的用例时，我感到失望。
我看到的很多网站，加上 AspectC++ 开发人员的演示，都提出了我认为相当可疑的用例。
他们讨论了如何使用 AOP 进行错误处理（抛出异常）、对参数和返回值进行边界检查、在出现问题时返回安全的空对象、安全性等。这些只是不好的例子吗（而不是实际使用）例），或者我错过了什么？
当您调用函数时，您应该如何知道发生了什么？事实上任何事情都有可能发生，这取决于你决定应用哪些方面。这不是会把事情搞得一团糟吗？ API文档呢，我该怎么写呢？
到目前为止，我见过的 AOP 唯一好的用例是日志记录或分析之类的东西 - 不会影响实际逻辑流程并且仅用作调试工具的东西。
AOP 除了调试机制之外还有其他用途吗？
Aspect Oriented Programming (AOP) seems like an interesting concept. At first I was pretty enthusiastic about it, but as I read more and saw the use cases people were describing I grew disappointed.
A lot of sites I saw, plus a presentation from the developers of AspectC++, presented use cases that I found rather dubious.
They talked about how AOP can be used to do error handling (throwing exceptions), do bounds checking on parameters and return values, return safe null objects in case something goes wrong, security, etc. Are these just bad examples (and not actual use cases), or am I missing something?
How are you supposed to be aware of what's happening when you call a function? Virtually anything can happen, depending on what aspects you decide to apply. Isn't that going to mess up things really really badly? What about API documentation, how am I supposed to write that?
So far the only good use cases for AOP I've seen are things like logging or profiling — things that don't influence the actual logic flow and serve only as debugging tools.
Is AOP useful for anything else other than debugging mechanisms?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您的关注点与应用程序的主要关注点无关（称为正交关注点）时，AOP 最有用。当您必须向现有代码添加关注点（例如为内部私人使用而构建的东西的安全性）或必须添加出于某种原因不适合您的域模型而不真正模糊您的功能时，它可以非常方便。业务逻辑。
我不会在任何你必须想知道调用函数时发生了什么的地方使用它。对我来说这似乎是代码味道。
AOP is most useful when you have concerns that aren't relevant to the main concern of your application (called orthogonal concerns). It can be super handy when you have to add a concern to existing code (say security to something that was built for internal private use) or have to add functionality that for whatever reason just doesn't fit into your domain model without really obscuring your business logic.
I wouldn't use it anywhere you have to wonder what is happening when you call a function. That seems like code smell to me.