分組相關常量類

Question

之間的共享。在有效的Java，第17項，喬希布洛赫認爲把靜態成員入的接口（和實現該接口）是被稱爲常數接口反模式一種不好的做法：

常量接口模式是接口使用不佳。類 內部使用一些常量是一個 實現細節。 實現 常數接口會導致此 實現細節泄漏到 類的導出API中。對於 類別的用戶，該類別實現常量 接口的結果是 。實際上，它甚至可能將它們混淆。更糟糕的是，它代表着一個 的承諾：如果在將來的版本中 類被修改，以至於它不再需要使用 這些常量，它仍然需要實現 接口來保證 的二進制兼容性。如果一個非正式的 類實現了一個常量接口，則其所有子類的接口中的常量 將污染其名稱空間的 。

Java平臺 庫中有幾個常量接口，如 java.io.ObjectStreamConstants。這些接口應視爲 異常，不應仿效。

我很自信我明白這背後的理由，並完全同意。

我的問題是：在接口與不可實例化的類中分組相關的常量（注意：這些不適用於枚舉，考慮相關常量pi和e的數學示例）是一個好主意，提供您只能通過靜態引用和靜態導入來訪問這些值，將隱藏在您的API中的interace保留爲默認訪問修飾符，並且永遠不會實現接口？

爲什麼或爲什麼不？除了能夠使用私有構造函數以確保常量分組類型從未實例化之外，是否有任何優勢將它們歸類到類中？

Answer 1

讓我們換個方式吧。使用常量接口沒有優勢。如您所知，接口用於定義合同，而不是常量。我沒有看到將interface關鍵字更改爲class關鍵字和使用public static final字段的問題。使用接口保持常量不是一個好主意。我認爲人們使用這種反模式是因爲他們不知道靜態導入（它是在Java 5.0中引入的），或者他們懶得派發它們的常量在適當的類中。相反，他們只是創建一個接口，讓每個類實現它。

編輯：順便說一句，這個問題聽起來像我 - 看看電視，用望遠鏡看附近的電視機，如果看到的是好的，是不是一個好主意。答案很簡單 - 不，望遠鏡是爲其他東西而發明的。啊，我知道這個例子是愚蠢的:)