最近我遇到了一段代碼，其中我發現了一個與只有常量的接口。而那些常量是在使用靜態導入的類中訪問的。常數在數量上更多（大約30到50）。只有常數的接口
就我個人而言，我認爲這不是一個好習慣。這就是爲什麼根據Effective Java被稱爲Constant Interface Antipattern。我沒有找到任何合理的理由去進行這種編碼。
此外，只有在應用程序中很少類需要導入少量常量時，才應該使用靜態導入。
你們中的任何人都可以讓我知道，如果有任何其他好的理由去只爲常量接口？
當然，在引入枚舉之前，如果有大量常量需要在多個類之間共享，那麼Constant Interface可能是最實用的方法。
如果這些常量只用於一個類，那麼其他答案中的註釋（'避免的模式'）是非常有效的 - 如果由使用它們的類聲明，它們將非常有用。
隨着更新版本的Java，我會向具有允許設置值的構造函數的枚舉轉移。然而，如果一組值只用於一個類，那麼最好在該類中聲明它們，而不是單獨聲明它們。
最近我碰到一個枚舉，它只有一個分號，它缺少一個包 - 私有構造函數（就像你通常看到的枚舉）。因此，用戶在這個枚舉中加入了公共的靜態最終變量，但似乎他們只是使用一個接口，如果這是他們所要做的。或者，還有更好的方法？如果他們不打算使用枚舉的實例構造函數，爲什麼要使用枚舉？ – djangofan 2016-12-16 17:18:50
如果這些常數進行一些邏輯分組，然後我可以使用一個枚舉代替
使用枚舉獲得什麼？如果常量有不同的類型，這是如何工作的？ – 2011-03-23 10:17:45
枚舉給你這麼多。對於這個特定的例子，「類型安全」將是一個很大的問題。如果你知道常量接口反模式，那麼你知道使用接口常量的一個缺點是「附帶的運行時工件幾乎沒有實際用途」，因爲運行時工件具有很多優點，因此enum – 2011-03-23 10:29:04
@PeterLawrey「How如果常量具有不同類型，這是否工作？「？如果他們都構成了一些邏輯分組的一部分，那麼你可以將你自己的類型本身枚舉爲 – 2011-03-23 10:31:14
我不喜歡這個成語在所有。爲什麼要將常量從它們使用的上下文中分離出來？我覺得很困惑。
這個設計強制一個類需要一個常量來實現一個完整的界面。所有這些常數都是公開的。
枚舉的想法是一個很好的想法。除此之外的任何東西。
此鏈路是否具有有效的討論涉及http://www.theserverside.com/discussions/thread.tss?thread_id=19221
和底線是避免儘可能您可以使用常量只有接口
這個解決方案不是很大，但有時是有最好的選擇所有常量都集中在一個地方，例如應用程序中使用的翻譯鍵。
使用接口我們可以創建這些接口的完整存儲並且不會複製它們。
完全沒有。我會盡可能避免這種模式，在我的書中完全不是。我傾向於將常數保持在最有意義的位置，或者從OO的角度來看，它們屬於哪個屬性，並且很少將它們組合到一個接口中。
另一種選擇（除了枚舉）將是一個非instatiatable類（私人構造函數）收集常量如果枚舉不適合（如字符串，整數等）。
另外，也許只有在使用它的地方纔會使該類可見。
一個常見的選擇是在工具類而不是接口中定義公共靜態最終常量。把你的常量接口，重新定義爲一個類，在每個聲明中放置「public static final」，並引用這些由類名限定的變量，而不是通過實現接口。
我會傾向於認爲一組常量與枚舉不同。
它不是很好，但通常沒有簡單的方法來收集大量的常量。你會認爲什麼是替代方案？ （通常情況更糟;） – 2011-03-23 09:56:06
@Peter Lawrey我們使用常量接口來存儲jdbc存儲過程名稱。這是一個很好的例外，還是不好的做法？ – 2011-03-23 09:59:58
如果所有名稱都具有相同的類型，並且它們都是相同類型的信息，那麼@Suraj建議使用'enum'會更好。然而，根據我的經驗，大多數接口常量更多是想要在類之間共享的幻數的隨機集合。 – 2011-03-23 10:36:55