2 回答

TA貢獻(xiàn)1794條經(jīng)驗(yàn) 獲得超8個(gè)贊
如果初始字符串在代碼庫(kù)的不同區(qū)域中使用,例如,如果您有兩個(gè)具有相同$VIDEOS路徑的不同 URL,則常量可能非常強(qiáng)大,因?yàn)槟梢砸淮尉庉嬎羞@些。然而,僅僅因?yàn)槌A俊翱赡堋庇迷诓煌牡胤骄蛣?chuàng)建它們,維護(hù)起來(lái)可能會(huì)是一場(chǎng)噩夢(mèng)。例如,如上所述,兩個(gè) API 使用該$VIDEOS路徑,但只有一個(gè)發(fā)生更改。
然而,另一方面,在這里使用可能有一個(gè)好處,那就是使用slug您的示例中的 , 但已編輯。
private const val SLUG = "thing"
@GET("videos/public/{$SLUG}")
fun getVideos(@Path($SLUG) slug: String, @Query("limit") limit: Int): List<Video>
因?yàn)檫@是在同一個(gè) API 調(diào)用中使用的,但在兩個(gè)區(qū)域內(nèi)。要點(diǎn)是你可以將事物變成常量,但前提是它有意義。盡量不要抽象掉整個(gè) API,因?yàn)橐坏┻@樣做,更改和維護(hù)就會(huì)變得更加困難。
當(dāng)有疑問(wèn)時(shí),我也會(huì)求助于庫(kù)本身的示例。Retrofit 文檔此處的示例沒(méi)有任何常量。

TA貢獻(xiàn)1829條經(jīng)驗(yàn) 獲得超13個(gè)贊
使用第二種方法,代碼變得更具可讀性 - 這是一個(gè)非常重要的優(yōu)勢(shì)。
使用第一種方法的優(yōu)點(diǎn)是,如果路徑的某些部分發(fā)生變化,則只能在一個(gè)地方進(jìn)行更改。但這是一個(gè)值得懷疑的優(yōu)勢(shì),因?yàn)槁窂胶苌俑淖?,而且第二個(gè)選項(xiàng)的改變也不需要太多時(shí)間。
第二種方法的缺點(diǎn):
創(chuàng)建了需要跟蹤的額外依賴項(xiàng),并且您可能會(huì)錯(cuò)誤地更改不需要的內(nèi)容,
您必須檢查每個(gè)常量中的內(nèi)容以確保路徑正確。
因此,答案是選項(xiàng) 2(常規(guī)字符串)更好。
添加回答
舉報(bào)