相關閱讀

每篇一句

只要學不死，就往死裡學。我們離過勞死都還遠著呢

1、概述

在編碼過程中，避免不了維護一些常量。而通過這麼多的專案中發現，使用方式都不盡相同。有用常量類的、有用介面的、有用列舉的，因此本文針對於常量的管理做一些討論

2、栗子

第一種使用介面：

public interface Constants{
   int AUDIT_STATUS_PASS = 1;
   int AUDIT_STATUS_NOT_PASS = 2;
}

第二種使用常量類:

public class Constans{
    public static final int AUDIT_STATUS_PASS =
 
 1;
    public static final int AUDIT_STATUS_NOT_PASS = 2;
}

第三種使用列舉:

@Getter
@AllArgsConstructor
public enum ChildType {

    NORMAL_PARENT(0, "正規課"),
    TRIAL_PARENT(1, "體驗課");
    
    private int id;
    private String name;
}

相比較第一種和第二種其實差不多，但第一種顯然更簡潔，因為不用寫public static final了嘛，更方便了。但是，但是，但是不建議在介面中定義常量。因為我在閱讀《Effective Java》這本書中提到過：

如果某個實現了常量介面的類被修改不再需要常量了，也會因為序列化相容原因不得不保持該實現，而且非final類實現常量介面會導致所有子類被汙染

所以我個人推薦：介面中的常量, 不應該用於全域性. 而應當用在與之相關的類中。這樣能保持很好的層級關係和隔離性，方便分包和擴充套件，具體請參考spring中對常量維護的原則。
當然，剛才說了不建議把一般的常量放在接口裡，所以我們可以放在常量類了，但建議常量類是final的。

什麼時候使用列舉呢？其實建議使用列舉。《Effective Java》中也是推薦使用列舉代替int常量的。列舉當然是首選，另如果不用列舉，在《Effective Java》一書中，作者建議使用一般類加私有構造方法的方式，至於為什麼不用介面，那就要上升到語言哲學問題了（可參考上面通俗易懂的話）。

此處個人不建議什麼都使用列舉來代替常量類。比如毫無規則歸類可言的一些常量：如SUCCUSS字串、金鑰串、路徑等等這些，可以放在一個常量類裡面糅在一起。而對於資料庫中對應type、status型別欄位並且是可以枚舉出來的，強烈建議使用enum型別，在平時獲取、使用、校驗起來常量無法比擬的，而且可以很少犯錯，非常大程度上增加程式碼的可讀性，這也是為什麼JDK5要推薦使用列舉類的原因吧。

最後，本人建議大家可以在設計程式碼的時候，多用介面規範程式碼，哪怕只是一個標記介面，也儘量為了長遠考慮而設計出來。通過讀spring、mybatis原始碼會發現裡面不乏一些標記介面，在向上抽象歸類判斷的時候，非常有用。

3、使用場景

大力推薦列舉型別的使用，讓他無處不在的去管理你的程式碼，可以讓程式碼結構更加清晰易懂可擴充套件。而常量類可以收集管理一些比較雜的一些常量。而介面的中的常量，在遵循開閉原則的基礎上，向上抽象管理自己的內聚的常量

4、最後

寫程式碼也是一種藝術，結構層次好的程式碼可以少出bug，提高效率。用一句話總結就是：設計良好的程式碼結構，儘量面向元資料程式設計。

知識交流

若群二維碼失效，請加微訊號（或者掃描下方二維碼）：fsx641385712。
並且備註：“java入群” 字樣，會手動邀請入群