我记得在 1990 年代末和 2000 年代初，面向方面编程 (AOP) 被认为是“下一件大事”。现在我看到一些 AOP 仍然存在，但它似乎已经消失在背景中。
【问题讨论】：
标签： language-agnostic aop
每件“下一件大事”都会发生这种情况。大量炒作，随后流行语的使用缓慢下降。但是，即使流行语逐渐消失并最终消失，它们背后的任何好想法往往都会留下来被主流吸收。
[编辑] 好的，对于那些认为我在“抨击”某些东西或声称面向方面的编程将会消失的人来说，这是一个例子。有一次，下一件大事是结构化编程。面向对象的编程就是从那里发展而来的，现在没有人谈论做“结构化编程”了。但是，在许多方面，我们仍在使用它最好的想法，因为 OOP 采用了它们，改进了它们，并添加了更多的新想法。
【讨论】：
我会建议它还不够大。这听起来很吸引人，但它真的让编码变得更容易了吗？我一直想尝试一下，找出它真正有什么好处，但我认为我在需要它提供的关系的地方做的编码不够。我不认为它像听起来那么有益。
此外，在这一点上，让多核编程变得更容易是一件大事，我认为面向方面的编程不会对此有所帮助。
您还可以在Adoption Risks 上找到很多内容。
【讨论】：
在一些项目中，我自己在最近一个项目中的经验是太容易被滥用 :( !!! 什么开始是一个很好的方式来设置调试、计时和在某种程度上扩展事务管理，它很快就被破坏了一段时间以来我见过的最奇怪、最难理解和调试的代码。
只是为了在调试/诊断方面进行一些扩展，AOP 代码生成的堆栈跟踪多次隐藏了异常发生的实际位置，无法识别。
【讨论】：
AOP 实际上非常出色，它的问题是没有现有的语言真正很好 支持它。当然 C# 具有属性（仅在您对事物进行编码时才有效），而 Java 具有“注入”（这会在运行时造成混乱），但总的来说，没有（主流）语言能够真正很好地支持它。 ..
所以它有点像最终成为一种“设计模式”（尽管在所有不同的语言中都有非常不同的实现），毕竟我猜这并不是那么糟糕；）
【讨论】：
在 2000 年代初期可能有很多炒作，发生的情况如下：有很多尝试创建面向方面的框架，这些尝试已合并为 Java 领域的两个重要项目: AspectJ 和 Spring AOP。 AspectJ 是完整的、复杂的、学术的、有点过度设计的。 Spring AOP 涵盖了 80% 的用例，具有 20% 的复杂性。
如果您查看 Google 趋势中的术语 "AspectJ, Spring AOP"，然后与 Java 本身的流行度相比，您会发现 AspectJ 的相对流行度有些恒定，但 Spring AOP 正在提高。这意味着人们使用 AOP，但不想要 AspectJ 的复杂性。我认为 AspectJ 的创造者犯了很多战术错误； AspectJ 一直是一个研究项目，并不是为“大众”设计的。
在 .NET 领域，我们在 2000 年代初看到了对 AOP 的类似兴趣。 2003年我开始做AOP研究的时候，.NET的AOP编织者有五六家；所有人都在遵循 AspectJ 的道路，并且都处于婴儿阶段。这些项目都没有幸存下来。基于这个分析，我构建了 PostSharp，它旨在以 20% 的复杂性覆盖 80% 的用例，但使用起来比 Spring AOP 方便得多。 PostSharp 现在被认为是 .NET 的主要方面编织器。 PostSharp 2.0 建立在 AspectJ 5 年的反馈和行业经验的基础上，并带来了“企业就绪”的 AOP（未来将判断这种说法是否值得）。除了 PostSharp，其他重要的参与者是 Spring Framework for .NET 和 Windsor Castle，这两个以 DI 为中心的应用程序框架提供了“也”方面（方面被认为是注入到构造对象中的依赖项）。由于这些技术使用运行时编织，因此它们具有严重的技术限制，因此实际上它们只能用于服务对象（这就是这些应用程序框架的设计目的）。 .NET 中的另一个启动项目是 LinFu，它可以做“也”方面。
简而言之，AOP 领域在过去几年经历了一些整合，并且可能进入了生产力阶段：客户会使用它，因为它真的很省钱，而不是因为它很酷。即使它很酷:)。
哦，我忘了：大多数应用服务器都内置了对 AOP 的支持。想到 JBoss、WebSphere 以及某种程度上的 WCF。
【讨论】：