Java中的常量：如何避免反模式
在應用中，我們往往需要一個常量文件，用于存儲被多個地方引用的共享常量。在設計應用時，我也遇到了類似的情況，很多地方都需要各種各樣的常量。
我確定需要一個單獨的文件來存儲這些靜態公共常量。但是我不是特別確定是應該用接口還是類（枚舉不滿足我的需求）。我有兩種選擇：
使用接口，如：
|
1 2 3 4 5 |
|
或
|
1 2 3 4 5 |
|
我的觀點是使用接口。因為接口會自動將成員變量設置為靜態的（static）、不可變的（final），這一點可以防止某些情況下錯誤地添加新的常量。這也使得代碼看起來更簡單和清晰。
同時，一個的簡單測試顯示，同樣的接口（字節碼文件）占用的空間是209個字節（ubuntu 14.04機器上），而類（字節碼文件）占用的空間是366個字節（同樣的操作系統）。更少的字節碼文件意味著加載和維護的成本更低。此外，JVM 加載接口的時候，不需要擔心類提供的額外特征（如重載、方法的動態綁定等），因此加載更快。
這看起來非常好，但是這是一個典型反模式的例子。雖然使用接口來保存常量看起很有幫助，但是這給應用后期的擴展留下一個漏洞。
假設存在在一個類，緊密】依賴于這些常量。開發者在該類中寫滿了通過接口對常量的引用。如：
|
1 |
|
所以，為了“清理”這段代碼，他可能想實現該接口，這樣他就不需要到處寫“packagename.Constants”，所有的常量可以直接訪問。
但是，一旦他實現了該接口，所有的常量就都變成“契約”（因為所有的常量都是公共的、靜態的）的一部分。這導致為這個類增加了不必要的常量。這會動搖整個基礎，并引起混亂。Java 中沒有一種方式可以阻止類實現接口。
而另一種方式，我們可以將類設置為final，這樣就不能擴展。甚至，我們可以將構造器設置為私有的，以防止對這個類實例化，這樣就永遠不會破壞約定。此外，如果一個特殊的常量在同一個類中被多次使用，則開發者可以使用靜態引入。
所有對于常量類，比較好的設計應該是：
|
1 2 3 4 5 6 7 |
|
靜態引入的例子：
|
1 2 3 4 5 6 |
|
這個設計問題也稱為接口常量反模式（Constant Interface Anti-pattern）。
原文鏈接： dzone 翻譯： ImportNew.com - paddx
譯文鏈接： http://www.importnew.com/16700.html
