为什么一些程序的loadClass,而不是在Java中
new'ing了类在Spring类,org.springframework.web.servlet.view.tiles2.TilesConfigurer
之一,下面的代码运行:为什么一些程序的loadClass,而不是在Java中
Class clazz = getClass().getClassLoader().loadClass(
"org.apache.tiles.extras.complete.CompleteAutoloadTilesInitializer");
this.tilesInitializer = (TilesInitializer) clazz.newInstance();
为什么不是作者只写
this.tilesInitializer = new org.apache.tiles.extras
.complete.CompleteAutoloadTilesInitializer()
输出有差异还是改进方法是第一种方式?
更新在TilesConfigurer在类的代码是完全如在第一个例子。它不会从DI层加载字符串。这是一个硬编码的字符串。
在第二种情况下,代码中存在依赖关系(在编译时),而在第一种情况下,依赖关系仅在运行此代码时创建。
做的事情可能是一对夫妇的原因是有用的第一种方式:
你想加快程序加载(在第二种情况下, 类加载器将加载在Apache瓷砖类和它的依赖时今年春天 类被加载,在第一种情况下它会等待做,直到今年春天代码 调用)
你想拥有的代码,可以单独站立,没有这种依赖性 (你可以在第二个案例如果没有 tiles.extras ....类文件,则不编译或加载代码,但在第一种情况下,您可以, ,如果存在,它们可能会提供一些额外的功能)。
如果您包含“tilesInitializer”的声明将是非常有用的。很可能它被声明为接口类型。
通过这种方式加载实际实现可以让您免于编译时依赖 - 您实际上不需要在类路径上实现CompleteAutoloadTilesInitializer来编译。它还允许您将实际类的选择加载到配置文件中。
另外,在运行时它不会产生任何UnresolvedClassReference-Exceptions,因为它们出现在类的静态初始化的某个地方,所以你不能轻易捕获/处理。
这使得可以响应以处理在确实围绕loadClass调用(通过选择不同的实现或禁用其提供的功能)的catch块中不可用的情况。这使用户只能部署他们真正使用的罐子。