Java中的常量避免反模式的方法_java

在應用中，我們往往需要一個常量檔案，用於儲存被多個地方引用的共用常量。在設計應用時，我也遇到了類似的情況，很多地方都需要各種各樣的常量。

我確定需要一個單獨的檔案來儲存這些靜態公用常量。但是我不是特別確定是應該用介面還是類（枚舉不滿足我的需求）。我有兩種選擇：

使用介面，如：

package one;public interface Constants {String NAME="name1";int MAX_VAL=25;}或package two;public class Constants {public static final String NAME="name1";public static final int MAX_VAL=25;}

我的觀點是使用介面。因為介面會自動將成員變數設定為靜態（static）、不可變的（final），這一點可以防止某些情況下錯誤地添加新的常量。這也使得代碼看起來更簡單和清晰。

同時，一個的簡單測試顯示，同樣的介面（位元組碼檔案）佔用的空間是209個位元組（ubuntu 14.04機器上），而類（位元組碼檔案）佔用的空間是366個位元組（同樣的作業系統）。更少的位元組碼檔案意味著載入和維護的成本更低。此外，JVM 載入介面的時候，不需要擔心類提供的額外特徵（如重載、方法的動態綁定等），因此載入更快。

這看起來非常好，但是這是一個典型反模式的例子。雖然使用介面來儲存常量看起很有協助，但是這給應用後期的擴充留下一個漏洞。

假設存在在一個類，緊密】依賴於這些常量。開發人員在該類中寫滿了通過介面對常量的引用。如：

複製代碼 代碼如下:

packagename.Constant.CONSTANT_NAME

所以，為了“清理”這段代碼，他可能想實現該介面，這樣他就不需要到處寫“packagename.Constants”，所有的常量可以直接存取。

但是，一旦他實現了該介面，所有的常量就都變成“契約”（因為所有的常量都是公用的、靜態）的一部分。這導致為這個類增加了不必要的常量。這會動搖整個基礎，並引起混亂。Java 中沒有一種方式可以阻止類實現介面。

而另一種方式，我們可以將類設定為final，這樣就不能擴充。甚至，我們可以將構造器設定為私人的，以防止對這個類執行個體化，這樣就永遠不會破壞約定。此外，如果一個特殊的常量在同一個類中被多次使用，則開發人員可以使用靜態引入。

所有對於常量類，比較好的設計應該是：

package three;//make the class non-extendable by adding final 增加final關鍵字來避免繼承public final class Constants {//Hide the constructor 隱藏構造器private Constants(){}public static String NAME="name";}

靜態引入的例子：

import static three.Constants.NAME;public class UseConstants { public static void main(String[] args) {   System.out.println("the value of constants is"+NAME); }}

這個設計問題也稱為介面常量反模式（Constant Interface Anti-pattern）。

以上就是java常量在使用過程中如何避免反模式的解決方案，希望對大家的學習有所協助。