类型化/通用方面值得付出努力吗？答案

【问题标题】：Are typed/generic aspects worth the effort?类型化/通用方面值得付出努力吗？
【发布时间】：2012-07-08 17:55:04
【问题描述】：

我对类型化/泛型方面做了一些研究。关于方面的一个重要事实是遗忘。因此，方面的关注点应该与领域关注点正交。尽管如此，还是有一些调查使 AspectJ 类型安全（StrongAspectJ）/使用泛型引入每个类型的方面。一篇论文提到了享元模式的实现作为一个方面。现在我想知道泛型方面是否还有更多用例？

【问题讨论】：

标签： spring aop aspectj postsharp

【解决方案1】：

PostSharp 是弱类型的，即建议将参数和返回值视为“对象”。 PostSharp 中对泛型方面有一些支持（方面可以是泛型类），但它不是很有用，因为建议是弱类型的。

请注意，在封面后面，PostSharp 生成的胶水代码是强类型的。但是当暴露在切面代码中时，一切都被向下转换为一个对象。

我正在考虑在 PostSharp 的下一个版本中实现强类型建议，可能支持泛型参数。原因是运行时性能，因为将值类型装箱到对象中会带来相当大的性能开销。请注意，泛型在 .NET 中的实现方式与在 Java 中不同，因此这点可能需要在两个平台上进行不同的讨论。

如果您的论文需要任何帮助，请随时与我联系。

【讨论】：

关于泛型 .NET 和 Java 之间区别的要点。

【解决方案2】：

自动生成一些样板到make a class callable via RMI 是另一个用例。该示例为一堆方法实现了一些环绕建议。

pointcut callsToServer(Type T):
    call(public T Server.*(..)) && this(Client)
T around(Type T): callsToServer(T) {
    T obj = null;
    try {
        obj = proceed();
    } catch (java.rmi.RemoteException ex) {}
    return obj;
}

泛型允许您说“我们将返回与方法签名所述类型相同的对象”。当然，如果我们只是返回对象，这是正确的。我们或许可以使用“抛出后”建议做类似的事情，但我们无法操纵返回值将 RemoteException 转换为空返回值。

【讨论】：

你的意思是什么我们也许可以用“投掷后”建议做类似的事情，但我们不能操纵返回值来将 RemoteException 转换为 null返回值。 ?我对 AspectJ 没有太多经验，我比较熟悉 PostSharp，它是 C# 的 AOP 框架。尽管如此，我认为 AspectJ 是最好的选择，因为它是 AOP 研究的领导者。
重点是 AspectJ 可以让您忽略不关心的通知中的返回值。在这些情况下，不需要泛型类型来保存返回值。 “抛出后”是仅在抛出异常时应用的建议，因此没有返回值。但是如果你想像这段代码那样操作返回值，你需要能够将它保存在一个变量中。如果切入点命中具有不同返回类型的多个连接点，您将从通用参数中受益。返回 null 而不是抛出异常就是这样一种情况。
同意这一点。另一方面，有许多使用另一种方法的 AOP 实现。您将获得一个包含参数和返回值的 IInvocation 对象。所以建议中没有return，除非你想早点退出。您可以在IInvocation 对象上设置的字段类型为object。因此，您几乎无法谈论类型安全。在我看来，您的 RMI 示例（以及我的轻量级！）是对 AOP 的某种滥用。在不了解 AOP 的情况下，我会对它们都使用工厂模式。即使使用 AOP，我会说它是更好的选择。
请不要误会我的意思。我正在为我的硕士论文做研究，这就是我如此怀疑的原因。 :)
IInvocation 可能变成 IInvocation 其中 V 是返回类型。我认为您不一定可以说这些示例是对 AOP 的滥用。不要忘记猴子补丁。 AOP 的一个主要用途是更改您无法控制的代码的行为。在这种情况下，这两个例子都是完全有效的。