框架中建立浮动框架_建立代理，而不是框架

框架中建立浮动框架

自从引入Java注释以来，它已成为大型应用程序框架API的组成部分。此类API的很好示例是Spring或Hibernate的示例，其中添加了几行注释代码可实现非常复杂的程序逻辑。尽管人们可以争论这些特定API的缺点，但大多数开发人员都会同意，这种使用正确的声明式编程形式具有很强的表现力。但是，只有很少的开发人员选择为其自己的框架或应用程序中间件实现基于注释的API，主要是因为它们难以实现。在下一篇文章中，我想说服您，相比之下，此类API的实现非常简单，并且使用正确的工具不需要任何有关Java内在函数的专门知识。

实施基于注释的API时，一个非常明显的问题是，正在执行的Java运行时未处理注释。结果，不可能为给定的用户注释分配特定的含义。例如，考虑我们想要定义一个@Log批注，该批注我们希望提供它用于简单地记录每次被注释方法的调用：

class Service {@Logvoid doSomething() { // do something ...}
}

由于@Log批注@Log其@Log就无法执行程序逻辑，因此，由批注的用户来执行请求的日志记录。显然，这使注释几乎无用，因为我们无法调用doSomething方法，并且期望在日志中观察到相应的语句。到目前为止，注释仅用作标记，而没有贡献任何程序逻辑。

缩小差距

为了克服这种明显的局限性，许多注释驱动的框架将子类与方法重写结合使用以实现与特定注释关联的逻辑。这通常称为子类检测。对于建议的@Log注释，子类检测将导致创建一个类似于以下LoggingService ：

class LoggingService extends Service {@Overridevoid doSomething() { Logger.log("doSomething() was called");super.doSomething();}
}

当然，上述类通常不需要显式实现。相反，一种流行的方法是仅在运行时使用诸如cglib或Javassist之类的代码生成库来生成此类。这两个库均提供用于创建程序增强子类的简单API。作为将类的创建延迟到运行时的一个很好的副作用，建议的日志记录框架无需任何特殊的准备就可以使用，并且始终与用户代码保持同步。如果将以更明确的方式创建类（例如通过在构建过程中编写Java源文件）来创建类，则情况并非如此。

但是，它可扩展吗？

然而，该解决方案带来了另一个缺点。通过将注释的逻辑放入生成的子类中，必须不再通过其构造函数实例化示例Service类。否则，仍将不记录带注释的方法的调用：显然，调用构造函数不会创建所需子类的实例。更糟糕的是，当使用建议的运行时生成方法时，由于Java编译器不知道运行时生成的类，因此LoggingService无法直接实例化。

因此，诸如Spring或Hibernate之类的框架使用对象工厂，并且不允许直接实例化被视为其框架逻辑一部分的对象。使用Spring，由于工厂的所有对象都是已经由框架首先创建的托管bean，因此自然可以通过工厂创建对象。同样，大多数Hibernate实体是作为查询结果创建的，因此不会显式实例化。但是，例如当保存尚未在数据库中表示的实体实例时，Hibernate的用户需要用存储后从Hibernate返回的实例替换最近保存的实例。通过查看有关Hibernate的问题，忽略这种替代已经构成了一个常见的初学者错误。除此之外，由于有了这些工厂，子类检测对于框架用户来说几乎是透明的，因为Java的类型系统暗示子类可以替代其任何超类。因此， LoggingService的实例可以在用户期望用户定义的Service类的实例的任何地方使用。

不幸的是，事实证明，这种批准的实例工厂方法难以实现建议的@Log注释，因为这将需要对可能被注释的类的每个单个实例使用工厂。显然，这将增加大量的样板代码。通过不将日志记录指令硬编码到方法中，我们甚至可能创建比我们避免的样板更多的样板。同样，意外使用构造函数会给Java程序带来细微的错误，因为此类实例上的注释将不再像我们期望的那样被对待。另一个问题是，工厂不容易构成。如果我们想向已经是Hibernate bean的类添加@Log注释怎么办？这听起来很琐碎，但需要进行大量配置才能合并两个框架的工厂。最后，最终的工厂膨胀的代码看起来不会太漂亮，以致于无法使用该框架进行迁移。这是使用Java代理进行检测的地方。这种低估的检测形式为讨论的子类检测提供了很好的选择。

一个简单的代理

Java代理由一个简单的jar文件表示。与普通Java程序类似，Java代理将某些类定义为入口点。然后，期望此类定义一个静态方法，该方法在调用实际Java程序的main方法之前将被调用：

class MyAgent {public static void premain(String args, Instrumentation inst) {// implement agent here ...}
}

处理Java代理时，最有趣的部分是premain方法的第二个参数，它表示Instrumentation接口的实例。通过定义ClassFileTransformer此接口提供了一种挂接到Java的类加载过程的方法。使用此类转换器，我们能够在Java程序首次使用之前对其进行增强。

乍一看，使用此API听起来似乎很直接，但它却带来了新的挑战。通过更改已编译的Java类（表示为Java字节码）来执行类文件转换。实际上，Java虚拟机不知道编程语言是什么Java。相反，它仅处理此字节码。还要感谢字节码抽象，JVM能够轻松运行其他语言，例如Scala或Groovy。结果，注册的类文件转换器仅提供将给定的字节（代码）数组转换为另一个数组的功能。

即使诸如ASM或BCEL之类的库提供了用于处理已编译Java类的简单API，也只有很少的开发人员具有处理原始字节码的经验。更糟糕的是，正确执行字节码操作通常很麻烦，甚至通过抛出令人讨厌且不可恢复的VerifierError来弥补虚拟机的小错误。幸运的是，有更好，更轻松的方式来处理字节码。

我编写和维护的Byte Buddy库提供了一个简单的API，用于处理已编译的Java类和创建Java代理。在某些方面，Byte Buddy是类似于cglib和Javassist的代码生成库。但是，除了那些库之外，Byte Buddy还提供了一个统一的API，用于实现子类和重新定义现有的类。但是，对于本文，我们只希望研究使用Java代理重新定义类。好奇的读者可以参考Byte Buddy的网页，该网页提供了有关其完整功能集的详细教程。

使用Byte Buddy作为简单代理

字节伙伴提供的一种定义工具的方法是使用依赖项注入。这样做，一个拦截器类（由任何普通的旧Java对象表示）都可以通过其参数的注释简单地请求任何必需的信息。例如，通过在“ Method类型的参数上使用Byte Buddy的@Origin批注，Byte Buddy可以@Origin出拦截器想知道要拦截的方法。这样，我们可以定义一个通用拦截器，该拦截器始终知道要拦截的方法：

class LogInterceptor {static void log(@Origin Method method) {Logger.log(method + " was called");} 
}

当然，Byte Buddy附带了更多注释。

但是，此拦截器如何表示我们打算用于拟议的日志记录框架的逻辑？到目前为止，我们仅定义了一个记录方法调用的拦截器。我们错过的是该方法的原始代码的后续调用。幸运的是，Byte Buddy的乐器是可以组合的。首先，我们为最近定义的LogInterceptor定义一个MethodDelegation ，默认情况下，该方法在每次调用方法时都会调用拦截器的静态方法。从此开始，我们可以随后以SuperMethodCall表示的原始方法代码的后续调用来组成委托：

MethodDelegation.to(LogInterceptor.class).andThen(SuperMethodCall.INSTANCE)

最后，我们需要告知Byte Buddy有关指定工具要拦截的方法的信息。如前所述，我们希望该工具适用于任何使用@Log注释的方法。在字节伙伴中，可以使用类似于Java 8谓词的ElementMatcher来标识方法的这种属性。在静态实用程序类ElementMatchers ，我们已经可以找到合适的匹配器来标识带有给定注释的方法： ElementMatchers.isAnnotatedWith(Log.class) 。

有了这些，我们现在可以定义一个实现建议的日志记录框架的代理。对于Java代理，Byte Buddy提供了一个实用程序API，该API建立在我们刚刚讨论的类修改API的基础上。与后一种API相似，它被设计为领域特定的语言，因此仅通过查看实现即可轻松理解其含义。如我们所见，定义这样的代理仅需要几行代码：

class LogAgent {public static void premain(String args, Instrumentation inst) {new AgentBuilder.Default().rebase(ElementMatchers.any()).transform( builder -> return builder.method(ElementMatchers.isAnnotatedWith(Log.class)).intercept(MethodDelegation.to(LogInterceptor.class).andThen(SuperMethodCall.INSTANCE)) ).installOn(inst);}
}

请注意，这种最小的Java代理不会干扰应用程序的其余部分，因为任何执行代码都会观察所检测的Java类，就像将日志记录语句硬编码到任何带注释的方法中一样。

现实生活如何？

当然，提出的基于代理的记录器是一个简单的例子。通常情况下，开箱即用的框架提供了类似的功能，例如Spring或Dropwizard都是很棒的。但是，对于如何解决编程问题，人们通常也对此类框架持意见。对于大量的软件应用程序，这可能不是问题。但是，有时这些意见会阻碍更大的发展。然后，围绕框架关于如何做事情的假设进行工作，不仅会导致一些问题，而且还会导致抽象的泄漏，并可能导致软件维护成本激增。尤其是当应用程序随着时间增长和变化，并且其需求与基础框架所提供的需求有所不同时，尤其如此。

相反，当以图片混合的方式组成更专业的框架或库时，一个简单地用另一个替换了有问题的组件。如果这两种方法都不起作用，甚至可以实施自定义解决方案，而不会干扰应用程序的其余部分。据我们了解，这似乎很难在JVM上实现，这主要是Java严格类型系统的结果。但是，使用Java代理很有可能克服这些类型限制。

我的观点是，我认为至少所有跨领域的关注都应该由代理驱动的专用库来解决，而不是由整体框架的内置模块来解决。我真的希望更多的应用程序会考虑这种方法。在最琐碎的情况下，使用代理在感兴趣的方法上注册侦听器并将其从那里获取就足够了。这种组成代码模块的间接方法避免了我在遇到的大部分Java应用程序中观察到的强大凝聚力。作为一个很好的副作用，它也使测试非常容易。与运行测试类似，在启动应用程序时不添加代理，可以有针对性地禁用某些应用程序功能，例如日志记录。所有这些都无需更改代码行，也不会使应用程序崩溃，因为JVM只是忽略了它在运行时无法解析的注释。安全性，日志记录，缓存，有许多原因应以建议的方式处理这些主题，甚至更多。因此，有时创建代理而不是框架。