爲什麼不推薦使用isJavaLetterOrDigit？

爲什麼不推薦使用isJavaLetterOrDigit的java.lang.Character？爲什麼不推薦使用isJavaLetterOrDigit？

該文檔說，應該使用方法isJavaIdentifierPart來代替，但不指明原因。這兩種方法的文檔是相同的。谷歌搜索這個問題沒有任何解釋。

實際上，一個源代碼搜索顯示，現在，只需調用另一個，所以行爲沒有區別。它是否被棄用，因爲它有一個更令人困惑的名字？看起來像一個相當奇怪的決定。

@Deprecated 
public static boolean isJavaLetterOrDigit(char ch) { 
    return isJavaIdentifierPart(ch); 
}

來源

2013-04-28 Antimony

舊的（不建議使用的）名稱沒有正確反映實際執行的內容;例如它接受既不是字母也不是數字的字符。我想這會導致一些「錯誤」報告和困惑的開發人員的支持請求。國際海事組織，這是他們採取（重大）創建新方法並貶低舊方法的最可能的原因。（@HuiZheng提出的其他原因是在知識層面上的有效點，但不足以證明不推薦使用方法。Java人不會僅僅依靠良好的API設計原則來繞過改變的API。爲開發人員提供工作，而Oracle不想疏遠支付這些程序員工資的公司，因爲Java作爲一個穩定平臺的聲譽，Java已經在企業界贏得了如此多的關注！）

無論如何，廢除這種方法似乎對我來說）就像一個明智的，合理的API設計決策。無論哪種方式，我們的意見都是沒有意義的。

來源

2013-04-28 02:49:31

原因1：

一個好的API名稱應該是足夠抽象的（但不是過於抽象）。 isJavaLetterOrDigit太實現導向。如果您確實想要這樣，請改用isLetterOrDigit。

原因2：

一個好的API名稱應確切指定其目的，應正確實施。 isJavaLetterOrDigit是誤稱，因爲它實際上允許使用非字母或數字字符，如「_」或「$」。

原因3：

一個好的API名稱應該是諧波與他人。 isJavaIdentifierPart與其他API一致，如isJavaIdentifierStart,isUnicodeIdentifierPart,isIdentifierIgnorable。

最後，僅僅因爲這兩個API之間的行爲沒有差異，並不意味着它們是相同的。誤導性的API名稱會破壞您的代碼。此外，總是儘快轉儲棄用的API，因爲它們最終（或很有可能）會被庫提供商傾銷。

來源

2013-04-28 03:08:22

由於二進制兼容性的原因，它們不能被庫提供者轉儲。 – EJP 2013-04-28 03:31:33

@EJP我知道兼容性原因，不贊成使用的API通常會保留一段時間。但從長遠來看，圖書館提供商可能會選擇打破這種兼容性。無論如何，我們不想冒這個風險。 – 2013-04-28 03:41:03

@惠正 - 根據以往的歷史，該方法不會被刪除。甲骨文或其（付費）客戶的利益並不在於這麼做。文件說這*可能會發生......但我預測它*不會*。（或者至少，除非Oracle能夠提供可靠的工具來自動升級源代碼和字節碼級別的舊代碼）。 – 2013-04-28 03:51:06

爲什麼不推薦使用isJavaLetterOrDigit？

回答

相關問題