Spring 类型化/泛型方面值得付出努力吗？

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

自动生成一些样板文件是另一个用例。该示例为一组方法实现了一些环绕建议

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转换为空返回值。

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

请注意，在封面后面，PostSharp生成的粘合代码是强类型的。但当暴露于方面代码时，对象的一切都是向下的

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

---

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

你说我们可能可以做类似于“抛出后”建议的事情，但我们无法操纵返回值将RemoteException转换为空返回值是什么意思？我对AspectJ没有太多经验，我更熟悉PostSharp，它是C#的AOP框架。尽管如此，我认为AspectJ是一个标签，因为它是AOP研究的领导者。重点是AspectJ可以让你忽略不关心它的建议中的返回值。在这些情况下，不需要泛型类型来保存返回值。“抛出后”是仅在抛出异常时应用的通知，因此没有返回值。但是，如果您想像这段代码那样操纵返回值，则需要能够将其保存在变量中。如果切入点命中多个具有不同返回类型的连接点，那么您将受益于泛型参数。返回null而不是抛出异常就是这样一种情况。同意这种说法。另一方面，有许多AOP实现使用另一种方法。您将得到一个包含参数和返回值的

IInvocation

对象。因此，通知中没有

返回

，除非您希望提前退出它。您可以在

IInvocation

对象上设置的字段类型为

object

。因此，您很难谈论类型安全性。在我看来，您的RMI示例（以及我的flyweight！）是对AOP的某种滥用。在不知道AOP的情况下，我会对它们都使用工厂模式。即使使用AOP，我也会说它是更好的选择。请不要误解我的意思。我正在为我的硕士论文做研究，这就是我如此怀疑的原因。：）IInvocation可能变成IInvocation，其中V是返回类型。我认为你不一定能说这些例子是AOP的误用。别忘了给猴子打补丁。AOP的一个主要用途是改变不受控制的代码的行为。在这种情况下，两个例子都是完全有效的。关于泛型.NET和Java之间的区别，这是一个很好的观点。