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

构造Resources.toString(Resources.getResource("foo"), Charsets.UTF_8)感觉有点麻烦。为什么要坚持转换为URL的第一个？由于getResource()方法不会抛出异常，为什么不同时使用并行String方法呢？为什么Guava Resources类没有String方法的版本？

来源

2012-02-21 Jherico

除非参与图书馆的答案或者有人引用，它的所有的猜测 - 不知道这是一个非常适合左右。我会猜测，因为URL是通用的，比字符串更通用。 – 2012-02-21 23:40:37

就我个人而言，我期望一个String重载接受一个'URL'作为一个字符串，而不是资源名称，因为我更习惯于使用URL（主要是因为Jetty的'ClassLoader'的资源处理的大脑充满了失败）。也许他们想避免含糊不清？ – FauxFaux 2012-02-22 00:01:37

@DaveNewton，绝大多数Guava团队（包括你的真人）_does_关注StackOverflow上的番石榴标签，并经常回答这些问题。我不知道这个问题的答案，所以我不能回答，但我认为在这里提出这样的问题是完全正确的，希望有一个番石榴团队成员回应。 – 2012-02-22 00:26:43

我很确定这一切都归结为正交性和可组合性。 API清楚地将获得URL的资源做东西与该资源。这很重要，因为您可以通过多种方式获取资源的URL。 Resources.getResource("foo")就是其中之一，但在某些情况下它不起作用。如果您需要确保使用特定的ClassLoader（因为Guava可能由您的应用程序文件加载了不同的ClassLoader），您需要另一种获取URL的方法，如Resources.getResource("foo", SomeApplicationClass.class)。

如果Resources提供了处理所有这些情况的方法的重载，则该类中方法的数量将增加三倍。可能似乎在这种特殊情况下是可以接受的，但是如果在整个库中添加了类似的“快捷方式”，方法的数量会很快膨胀起来。图书馆将变得更加难以消化，因为你不得不挖掘出几乎相同的方法来找到你想要的东西。出于这个原因，番石榴倾向于强大的方法来完成一件事，并且与其他方法很好地结合在一起。结合Resources.toString与Resources.getResource就是一个例子。

当然，这并不意味着番石榴从来没有提供了这样的快捷方式......它只是这样做，当增加真的看起来值得。例如，大多数的的Files类中的方法可以中去除，因为你可以结合Files.newInputStreamSupplier，Files.newWriterSupplier等与在ByteStreams和CharStreams类的方法来完成同样的事情。但鉴于File上的常见操作，快捷键被认为是值得的。（请注意，采取String名重载是不增加，虽然）。

来源

2012-02-22 02:34:05 ColinD

如果Resources.getResource（）抛出异常或其他问题，那么这会更具吸引力。我几乎从来没有在我的代码中玩过类装载器，所以对我来说，它只是感觉像一个额外的箍环跳过。但感谢您的答案。 – Jherico 2012-02-22 22:21:34

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

回答

相关问题