构造Resources.toString(Resources.getResource("foo"), Charsets.UTF_8)感觉有点麻烦。为什么坚持首先转换为URL？由于getResource()方法不会抛出异常，为什么不同时使用并行String方法？
答案 0 :(得分：7)
我很确定这一切都归结为正交性和可组合性。 API清楚地将获取资源的URL与使用该资源进行某事分开。这很重要，因为您可以通过多种方式获取资源的URL。 Resources.getResource("foo")是一个，但在某些情况下它不起作用。如果您需要确保使用特定的ClassLoader（因为Guava可能由与您的应用程序文件不同的ClassLoader加载），您需要一种获取URL的替代方法，例如Resources.getResource("foo", SomeApplicationClass.class)。
如果Resources提供其方法的重载来处理所有这些情况，则类中的方法数将增加三倍。在这种特殊情况下，可能似乎是可以接受的，但如果在整个库中添加了类似的“快捷方式”，那么方法的数量会迅速增加。图书馆将变得更加难以消化，因为你必须深入挖掘大致相同的方法才能找到你想要的东西。出于这个原因，Guava喜欢强大的方法，这些方法可以完成一件事并与其他方法很好地结合。将Resources.toString与Resources.getResource结合起来就是一个例子。
当然，这并不意味着Guava 永远不会提供这样的捷径......它只是在添加真正值得的时候才这样做。例如，Files类中的大部分方法都可以删除，因为您可以将Files.newInputStreamSupplier，Files.newWriterSupplier等与{中的方法相结合{1}}和ByteStreams类来完成相同的事情。然而，考虑到CharStreams的常见操作，快捷方式被认为是值得的。 （请注意，采用File文件名的重载是而不是。）