爲什麼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方法的版本？

回答

相關問題