詳細(xì)聊聊JDK中的反模式接口常量

更新時間：2022年01月07日 09:20:35 作者：看山灬

這篇文章主要給大家介紹了關(guān)于JDK中反模式接口常量的相關(guān)資料,文中通過實例代碼介紹的非常詳細(xì),對大家學(xué)習(xí)或者使用jdk具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下

前言

在實際開發(fā)過程中，經(jīng)常會需要定義一個文件，用于存儲一些常量，這些常量設(shè)計為靜態(tài)公共常量（使用 public static final 修飾）。這個時候就出現(xiàn)兩種選擇：

在接口中定義常量，比如 JDK 1.1 中的 java.io.ObjectStreamConstans 接口；
在類中定義常量，比如 JDK 1.7 中的 java.nio.charset.StandardCharsets；

這兩種方式都能夠達(dá)到要求：存儲常量、無需實例化。下面分情況討論下兩種方式孰優(yōu)孰劣。

常量接口

首先從代碼的角度分析，接口中定義的變量都必須是常量，即默認(rèn)使用 public static final 修飾。也就是說，在寫代碼的時候直接寫成下面這樣：

public?interface?ObjectStreamConstants?{
????short?STREAM_MAGIC?=?(short)0xaced;
????short?STREAM_VERSION?=?5;
}

但是在類中就必須乖乖的寫成下面這種樣子：

public?final?class?ObjectStreamConstants?{
????public?static?final?short?STREAM_MAGIC?=?(short)0xaced;
????public?static?final?short?STREAM_VERSION?=?5;
}

從直觀的感受，接口寫起來方便多了。第二個問題：因為類中寫的字符比接口多，所以編譯之后文件大小也是類文件比接口文件大。第三個問題：在JVM加載過程中，接口沒有類提供的額外特種（如重載、方法的動態(tài)綁定等），所以接口加載比類快。分析到此，似乎沒有什么理由不用接口定義常量了。但是，BUT，這種做法卻是一種嚴(yán)重的反模式行為。引用《Effective Java》中的一段描述：

The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.

翻譯出來就是：

常量接口模式是對接口的不良使用。類在內(nèi)部使用某些常量，這純粹是實現(xiàn)細(xì)節(jié)。實現(xiàn)常量接口會導(dǎo)致把這樣的實現(xiàn)細(xì)節(jié)泄露到該類的導(dǎo)出API中。類實現(xiàn)常量接口，這對于類的用戶來講并沒有什么價值。實際上，這樣做反而會使他們更加糊涂。更糟糕的是，它代表了一種承諾：如果在將來的發(fā)行版本中，這個類被修改了，它不再需要使用這些常量了，它依然必須實現(xiàn)這個接口，以確保兼容性。如果非final類實現(xiàn)了常量接口，它的所有子類的命名空間也會被接口中的常量所“污染”。

這樣說來就很明白透徹了：

接口是不能阻止被實現(xiàn)或繼承的，也就是說子接口或?qū)崿F(xiàn)中是能夠覆蓋掉常量的定義，這樣通過父、子接口(或?qū)崿F(xiàn)) 去引用常量是可能不一致的；
同樣的，由于被實現(xiàn)或繼承，造成在繼承樹中可以用大量的接口、類或?qū)嵗ヒ猛粋€常量，從而造成接口中定義的常量污染了命名空間；
接口暗含的意思是：它是需被實現(xiàn)的，代表著一種類型，它的公有成員是要被暴露的API，但是在接口中定義的常量還算不上API。

綜上所述：使用接口定義常量，是一種不可取的行為。JDK中定義的接口常量（例如java.io.ObjectStreamConstans）應(yīng)該算是反面教材。

類接口

既然使用接口第一常量不可取，那就只能通過類定義常量了。雖然在JAVA中類不能夠多繼承，但是子類也能夠“污染”父類定義常量的命名空間。所以為了常量不可變，需要將常量類定義為final的，然后再徹底點(diǎn)就是再定義個private的構(gòu)造函數(shù)。就像java.nio.charset.StandardCharsets一樣：

public?final?class?StandardCharsets?{
????private?StandardCharsets()?{
????????throw?new?AssertionError("No?java.nio.charset.StandardCharsets?instances?for?you!");
????}
????public?static?final?Charset?US_ASCII?=?Charset.forName("US-ASCII");
????public?static?final?Charset?ISO_8859_1?=?Charset.forName("ISO-8859-1");
????public?static?final?Charset?UTF_8?=?Charset.forName("UTF-8");
}

在java.nio.charset.StandardCharsets中，為了阻止各種形式的實例化，甚至在構(gòu)造函數(shù)中拋出錯誤，也是做個夠徹底的了。

枚舉類型

但是，BUT，還有一種情況，比如常量中定義性別：男、女，使用上面的類常量，需要寫成：

public?final?class?Gender?{
????private?Gender()?{
????????throw?new?AssertionError("No?x.y.z.Gender?instances?for?you!");
????}
????public?static?final?int?MALE?=?1;
????public?static?final?int?FEMALE?=?0;
}

因為定義的性別類型實際是int，如果手賤寫成m.setGender(3)也是沒有錯誤的，那3又是什么鬼？是不是還要有4、5、6、7？那這種常量定義就失去價值了。對于這種可以歸類的常量，最好的常量定義方法應(yīng)該就是枚舉了：

public?enum?Gender?{
????MALE,?
????FEMALE
}

根據(jù)編輯的字節(jié)碼，Gender實際是：

public?final?class?Gender?extends?java.lang.Enum?{
????public?static?final?Gender?MALE;
????public?static?final?Gender?FEMALE;
}

這樣對于接受 Gender 類型參數(shù)的方法就只能傳入 MALE 或 FEMALE 了，不再有其他選項，這就是枚舉的意義。在后來的JDK中，也出現(xiàn)了像java.nio.file.StandardOpenOption等的枚舉定義。而且枚舉的定義也不只局限于這種，還有很多其他復(fù)雜定義，可以適用各種情況，以后再慢慢討論。