從Java 16以後,記錄類別成為正式特性,若在網路上搜尋它的相關文件,通常會先看到自行實作equals、hashCode、toString的範例,然後強調寫這些程式碼有多麻煩,而且容易出錯,同時,還連帶說明:雖然整合開發環境可以自動產生這些方法,不過,要是修改了類別成員、卻忘了重新生成方法,會引來什麼樣的臭蟲之類,接著,當中又示範了記錄類別的語法,歌頌「多簡潔!一點也不囉嗦!」

免除語法囉嗦?

單純從編譯器會自動生成equals等方法來看,「不囉嗦」這點是真的!然而,是哪方面因為「不囉嗦」而獲得益處呢?如果只是為了可以自動生成這些方法,那麼,用Lombok就好了啊?有人會說:那不是標準,但別忘了,Java本身也有JSR269(可參考先前專欄〈從Lombok到JSR269〉)。

能自動生成相關方法,純粹就只是針對語法上來示範記錄類別,畢竟Java一直都以囉嗦聞名,能少寫一些程式碼這件事,很容易說服大家這是個重大改進的特性,程式碼示範上也很簡單,只不過若因為這樣就埋單此一特性,之後當試著將記錄類別用於POJO、JavaBean等場合時,會發現記錄類別限制很多,一點也不好用!

例如,記錄類別的狀態是不可變動(immutable)(也就不適用於各種POJO)、不能在類別本體去定義非static的值域(field)、生成的取值方法會與規範建構式(canonical constructor)的引數同名(因此它不是個JavaBean)、不能被繼承等限制,需要equals等方法的場合很多,然而,這些場合不見得需要這些限制。

如果真正要瞭解記錄類別,我們不應該從一開始就從equals等方法可以自動生成來看待它。例如,面對以下的記錄類別定義,不應該強調它的語法有多簡潔:

public record Point(float x, float y) {}

記錄類別的語義

對於方才定義的Point記錄類別,在語義上是在告訴其他人,這裡定義了點,用來記錄點的資料,資料是以x與y的順序構成,某個Point實例的x、y值,就是某點唯一的狀態,除此之外沒有別的意涵了。

如果資料必須轉換為其他的資料呢?例如,將目前的資料轉換為JSON格式的字串?資料與資料之間的轉換,確實是一個需求,因此,可以在記錄類別的本體中定義方法,例如toJSON、fromJSON:

public String toJSON() {
return "{\"x\":%f,\"y\":%f}".formatted(x(), y());
}
public static Point fromJSON(String json) {
// 剖析JSON字串得到x,y
return new Point(x, y);
}

這類需求的方法定義加到記錄類別中,在語義上仍然明確地表示了:這些方法是與資料相關的處理;那麼,記錄類別可以當成JavaBean來使用嗎?JavaBean其實有多種角色,如果JavaBean只是作為資料載體,確實可以在記錄類別中定義取值函式(Getter),而在無參數建構式中,必須以預設值呼叫規範建構式,不過,無法提供設值函式(Setter),也就是說,最多當個純取值的JavaBean。

記錄類別在語義上,就是作為不可變動的資料載體,畢竟JEP 395一開頭的摘要,就明確地寫到「記錄類別就是不可變資料的透明載體(transparent carriers )」,透明指的是,無論是在名稱、結構、狀態上,記錄類別都明確地曝露、表現出來,沒有任何隱藏。

封裝的邊界

物件導向經常談到封裝,然而,封裝的對象或意圖其實是多元的,也許是想隱藏狀態、不曝露實作、遮蔽資料的結構、管理物件複雜的生命週期、隔離物件間的相依關係等,大部分情況下,封裝都意謂著某種程度的隱蔽性,藏起什麼東西之類的。

然而,作為一個資料載體時,只是單純地將一組資料聚合在一起,這些資料在名稱、結構,以及聚合後的整體名稱(就數學上,資料的組成構成了一個集合,例如點的集合),都是透明的,物件在外觀表現上會曝露一切,白話來說,物件本身提供的API,會與物件想表現的資料耦合在一起。

這使得資料載體的封裝,與其他的封裝意圖大相徑庭,因為就其他封裝的意圖來說,往往會希望物件本身提供的API,能夠隱藏物件本身(內部)的資料等東西;資料載體本身的意圖就是曝露資料的一切,然而,就Java來說,無論是哪種封裝,都必須透過class來定義,從而才造就了簡單的需求,也需要囉嗦的定義過程。

現代許多軟體之間,有諸多資料交換的需求,在Java定義資料載體時的囉嗦,催生了記錄類別。因為資料載體在外觀表現上,就是要曝露一切,也就不能有private的值域;記錄類別必須是不可變動,因為,可變動代表有隱藏的狀態;記錄類別不可繼承,因為繼承也代表著有狀態隱藏的可能性,想想看,若能繼承Point定義Point3D,將Point3D實例傳給接受Point的方法,從方法實作的觀點來看,如何能確定它接受到的物件只有x與y呢?

在API上表現一切,就是為什麼記錄類別會需要設下相關限制的原因,而這些限制,使得equals、hashCode的產生,可以單純化(可變動、可繼承會令其複雜化的幾個原因,可參考〈物件相等性〉),這只是語義上的要求,連帶使得語法上得以獲得簡化罷了。

記錄類別並不單純是語法糖的原因,就在於其語義,也就是外觀表現上要曝露一切,不可變動等相關的限制,就是要避免隱藏狀態,由於一切都揭露了,面對一個記錄類別的實例,在拆解其狀態時,就會出現類似的流程,因而,在未來版本的Java中,會有針對記錄類別的解構模式比對來支援這個流程,也就是JEP 405提案的內容。

優先思考語義

在其他的語言中,有著類似記錄類別的元素,像是Scala的案例類別(case class)、Kotlin的資料類別(data class)等,就算是動態定型語言,例如Python,也有@dataclass裝飾器,雖然Java也從這些語言中吸收了相關經驗,不過,這些元素在各自語言中,有各自不同的語義,這也是為何Java使用record作為關鍵字作為區別,以免與其他語言中類似元素間產生混淆。

Java作為一門古老的語言,本身已經有許多語法,要加入新語法會是件慎重、需要諸多考量的任務,僅僅是為了少寫些程式的語法糖,往往不足以構成納入新語法的理由,這也是Java常被批評為保守的理由之一。

因此面對記錄類別,或者是模式匹配、彌封類別(sealed class)等新特性,最好的方式是從語義上理解它們,必要時,可以深入閱讀相對應的JEP,因為JEP往往記載了新特性提案的前因後果。

若能從語義上瞭解新特性存在的意義,語法上若是有簡化等相關優點,往往只是附帶罷了,因為理解了語義,善用相關語法,才能讓意圖更明確,也才能將相關的限制,作為避免逾越語義的防火牆,將這類特性發揮在最適合的場合。

作者簡介


熱門新聞

Advertisement