为什么Guava Resources类没有方法的String版本？

Question

该构造Resources.toString(Resources.getResource("foo"), Charsets.UTF_8)感觉有点麻烦.为什么坚持首先转换为URL？由于该getResource()方法不会抛出异常,为什么不同时使用并行String方法？

Answer 1

我很确定这一切都归结为正交性和可组合性.该API明确分离得到了URL从资源做一些与该资源.这很重要,因为您可以通过多种方式获取URL资源.Resources.getResource("foo")是一个,但在某些情况下它不会起作用.如果您需要确保特定ClassLoader使用(因为番石榴可以通过不同的加载ClassLoader比你的应用程序文件),你需要获得的另一种方式URL,例如Resources.getResource("foo", SomeApplicationClass.class).

如果Resources要提供其方法的重载来处理所有这些情况,则类中的方法数量将增加三倍.这可能会在这种特殊情况下似乎可以接受的,但如果类似的"快捷方式"在整个库添加,方法的数量将非常迅速膨胀起来.图书馆将变得更加难以消化,因为你必须深入挖掘大致相同的方法才能找到你想要的东西.出于这个原因,Guava喜欢强大的方法,这些方法可以完成一件事并与其他方法很好地结合.结合Resources.toString与Resources.getResource是这样的一个例子.

当然,这并不意味着Guava 永远不会提供这样的捷径......它只是在添加真正值得的时候才这样做.例如,大多数在方法Files的类可以被删除,因为你可以结合起来Files.newInputStreamSupplier,Files.newWriterSupplier等用的方法ByteStreams和CharStreams类来完成同样的事情.File然而,考虑到s的常见操作,快捷方式被认为是值得的.(请注意,不会添加带有String文件名的重载.)