在這個問題中，出現(xiàn)了一個問題，可以通過將使用通用類型參數(shù)的嘗試更改為關(guān)聯(lián)類型來解決。這提示了一個問題“為什么關(guān)聯(lián)類型在這里更合適？”，這使我想知道更多。引入關(guān)聯(lián)類型的RFC表示：該RFC通過以下方式闡明了特征匹配：將所有特征類型參數(shù)視為輸入類型，以及提供關(guān)聯(lián)的類型，它們是輸出類型。RFC使用圖結(jié)構(gòu)作為激勵示例，并且在文檔中也使用了圖結(jié)構(gòu)，但我承認(rèn)，與類型參數(shù)化版本相比，我不完全意識到關(guān)聯(lián)類型版本的好處。最主要的是，該distance方法不需要關(guān)心Edge類型。很好，但是似乎根本沒有關(guān)聯(lián)類型的原因。我發(fā)現(xiàn)關(guān)聯(lián)類型在實踐中使用起來非常直觀，但是當(dāng)我決定在自己的API中何時何地使用它們時，我發(fā)現(xiàn)自己很掙扎。在編寫代碼時，何時應(yīng)在泛型類型參數(shù)上選擇關(guān)聯(lián)的類型，何時應(yīng)相反？