Java中的常量:如何避免反模式

ImportNew發表於2015-09-22

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

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

使用介面,如:

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)。

相關文章