我們與同事進行了討論，但沒有達成共識。我將感謝良好的論據和真實的使用體驗。問題是：聲明 URL 路徑的更好方法是什么，例如在使用 Retrofit 的 Android 應用程序中？對 URL 中的所有路徑項使用單獨文件中的靜態字符串常量。 @GET("$VIDEOS/$PUBLIC/{$SLUG}") fun getVideos(@Path(SLUG) slug: String, @Query(LIMIT) limit: Int): List<Video>使用常規字符串。 @GET("videos/public/{slug}") fun getVideos(@Path("slug") slug: String, @Query("limit") limit: Int): List<Video>
2 回答
慕田峪9158850
TA貢獻1794條經驗 獲得超7個贊
如果初始字符串在代碼庫的不同區域中使用，例如，如果您有兩個具有相同$VIDEOS路徑的不同 URL，則常量可能非常強大，因為您可以一次編輯所有這些。然而，僅僅因為常量“可能”用在不同的地方就創建它們，維護起來可能會是一場噩夢。例如，如上所述，兩個 API 使用該$VIDEOS路徑，但只有一個發生更改。
然而，另一方面，在這里使用可能有一個好處，那就是使用slug您的示例中的 , 但已編輯。
private const val SLUG = "thing"
@GET("videos/public/{$SLUG}")
fun getVideos(@Path($SLUG) slug: String, @Query("limit") limit: Int): List<Video>
因為這是在同一個 API 調用中使用的，但在兩個區域內。要點是你可以將事物變成常量，但前提是它有意義。盡量不要抽象掉整個 API，因為一旦這樣做，更改和維護就會變得更加困難。
當有疑問時，我也會求助于庫本身的示例。Retrofit 文檔此處的示例沒有任何常量。
烙印99
TA貢獻1829條經驗 獲得超13個贊
使用第二種方法，代碼變得更具可讀性 - 這是一個非常重要的優勢。
使用第一種方法的優點是，如果路徑的某些部分發生變化，則只能在一個地方進行更改。但這是一個值得懷疑的優勢，因為路徑很少改變，而且第二個選項的改變也不需要太多時間。
第二種方法的缺點：
創建了需要跟蹤的額外依賴項，并且您可能會錯誤地更改不需要的內容，
您必須檢查每個常量中的內容以確保路徑正確。
因此，答案是選項 2（常規字符串）更好。
添加回答
舉報
0/150
提交
取消