Java中怎么實現(xiàn)一個不可變類

Java中怎么實現(xiàn)一個不可變類，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

在 Java 中實現(xiàn)不可變類

諸如 Java、Ruby、Perl、Groovy 和 C# 一類的現(xiàn)代面向?qū)ο笳Z言都擁有一些內(nèi)置的便利機制，這些機制使得以可控方式來修改狀態(tài)變得很容易。然而，狀態(tài)對于計算來說是如此基礎(chǔ)的信息，因此您永遠也無法預(yù)料它會在哪個地方出紕漏。例如，由于大量可變化機制的存在，因此用面向?qū)ο蟮恼Z言編寫高性能的、正確的多線程代碼會很困難。因為 Java 已針對操縱狀態(tài)進行了優(yōu)化，因此您不得不繞過這樣的一些機制來獲得的不變性的一些好處。不過一旦您了解了要避免的一些陷阱之后，在 Java 中構(gòu)建不可變類這件事情就會變得非常容易。

定義不可變類

要將一個 Java 類構(gòu)造成不可變的類，您必須執(zhí)行以下操作：

把所有的域聲明成 final。

在 Java 中將域定義成 final 之后，您必須在聲明的時候初始化它們，或是在構(gòu)造函數(shù)中初始化它們。如果您的 IDE 抱怨您沒有在聲明的時候初始化它們，別緊張；當(dāng)您在構(gòu)造函數(shù)中寫入適當(dāng)?shù)拇a后，他們就會意識到您知道自己在做什么。

將類聲明為 final，這樣就不會重寫它。

如果可以重寫類的話，則可以重寫它的方法的行為，因此您最安全的選擇就是不允許將類子類化。注意，這就是 Java 的 String 類使用的策略。

不要提供一個無參數(shù)的構(gòu)造函數(shù)。

如果您有一個不可變對象，則必須要在構(gòu)造函數(shù)中設(shè)置該對象將包含的任何狀態(tài)。如果沒有狀態(tài)要設(shè)置，那么要一個對象來干什么？無狀態(tài)類的靜態(tài)方法一樣可以起到很好的作用；因此，您永遠都不該為一個不可變類提供一個無參數(shù)的構(gòu)造函數(shù)。如果您正在使用的框架因為某些原因需要使用這樣的構(gòu)造函數(shù)的話，那么您可以了解以下能否通過提供一個私有的無參數(shù)構(gòu)造函數(shù)（這是經(jīng)由反射可見的）來滿足這一要求。

需要注意的一點是，無參數(shù)構(gòu)造函數(shù)的缺失違反了 JavaBeans 的標準，該標準堅持要有一個默認的構(gòu)造函數(shù)。不過 JavaBeans 無論如何都不可能是不可變的，這是 setXXX 方法的工作方式所決定的。

至少提供一個構(gòu)造函數(shù)。

如果您沒有提供一個無參數(shù)構(gòu)造函數(shù)的話，那么這是您給對象添加一些狀態(tài)的最后機會！

除構(gòu)造函數(shù)之外，不再提供任何的可變方法。

您不僅要避免典型的受 JavaBeans 啟發(fā)的 setXXX 方法，還必須注意不要返回可變的對象引用。對象引用被聲明為 final，這是實情，但這并不意味這您無法更改它所指向的內(nèi)容。因此，您需要確保您已經(jīng)防御性地復(fù)制了從 getXXX 方法中返回的任何對象引用。

“傳統(tǒng)的” 不可變類

清單 1 中列出了一個滿足上述要求的不可變類：

清單 1. Java 中的不可變的 Address 類

public final class Address {private final String name;private final List<String> streets;private final String city;private final String state;private final String zip;public Address(String name, List<String> streets, String city, String state, String zip) {this.name = name;this.streets = streets;this.city = city;this.state = state;this.zip = zip;}public String getName() {return name;}public List<String> getStreets() {return Collections.unmodifiableList(streets);}public String getCity() {return city;}public String getState() {return state;}public String getZip() {return zip;}}

需要注意的一點是，可以使用 清單 1 中的 Collections.unmodifiableList() 方法對 streets 列表進行防御性復(fù)制。您應(yīng)該始終使用集合而不是數(shù)組來創(chuàng)建不可變列表，盡管防御性的數(shù)組復(fù)制也是可行的，但這會帶來一些不希望見到的副作用?？紤]一下清單 2 中的代碼：

清單 2. 使用數(shù)組而非集合的 Customer 類

public class Customer {public final String name;private final Address[] address;public Customer(String name, Address[] address) {this.name = name;this.address = address;}public Address[] getAddress() {return address.clone();}}

在您嘗試著在從 getAddress() 方法調(diào)用中返回的克隆數(shù)組上進行任何操作的時候，清單 2 中的代碼問題就暴露出來了，如清單 3 所示：

清單 3. 展示了正確但非直觀結(jié)果的測試

public static List<String> streets(String... streets) {return asList(streets);}public static Address address(List<String> streets, String city, String state, String zip) {return new Address(streets, city, state, zip);}@Test public void immutability_of_array_references_issue() {Address [] addresses = new Address[] {address(streets("201 E Washington Ave", "Ste 600"), "Chicago", "IL", "60601")};Customer c = new Customer("ACME", addresses);assertEquals(c.getAddress()[0].city, addresses[0].city);Address newAddress = new Address(streets("HackerzRulz Ln"), "Hackerville", "LA", "00000");// doesn't work, but fails invisiblyc.getAddress()[0] = newAddress;// illustration that the above unable to change to Customer's addressassertNotSame(c.getAddress()[0].city, newAddress.city);assertSame(c.getAddress()[0].city, addresses[0].city);assertEquals(c.getAddress()[0].city, addresses[0].city);}

在返回一個克隆數(shù)組的時候，您保護了底層的數(shù)組，但您交還的數(shù)組看起來就像是一個普通的數(shù)組，也就是說，您可以修改該數(shù)組的內(nèi)容（即使持有該數(shù)組的變量是 final，因為這只在數(shù)組引用自身上起作用，在非數(shù)組的內(nèi)容上不起作用）。在使用 Collections.unmodifiableList() （以及 Collections 中用于其他類型的一系列方法）時，您會收到一個對象引用，它沒有改變方法的可用性。

更清晰的不可變類

您可能經(jīng)常聽到這樣的說法：您還應(yīng)該將不可變域聲明為私有域。在聽到有人以一種不同的、但明確的看法來澄清一些根深蒂固的臆斷之后，我不再同意這樣的觀點了。在 Michael Fogus 對 Clojure 的創(chuàng)建者 Rich Hickey 所做的訪談中），Hickey 談到了 Clojure 的許多核心部分都缺少數(shù)據(jù)隱藏式的封裝。Clojure 在這一方面一直困擾著我，因為我是如此沉迷基于狀態(tài)的思考方式。

但在那之后，我意識到了，如果域是不可變的話，則無需擔(dān)心它們被暴露出來。許多我們用在封裝中的保障措施實際上就是為了防止發(fā)生改變，一旦我們梳理清楚了這兩個概念，一種更清晰的 Java 實現(xiàn)就浮現(xiàn)了出來。

請考慮清單 4 中的 Address 類版本：

清單 4. 使用了公共不可變域的 Address 類

public final class Address {private final List<String> streets;public final String city;public final String state;public final String zip;public Address(List<String> streets, String city, String state, String zip) {this.streets = streets;this.city = city;this.state = state;this.zip = zip;}public final List<String> getStreets() {return Collections.unmodifiableList(streets);}}

在您想要隱藏底層表示形式的時候，只有為不可變域聲明公共的 getXXX() 方法才會帶一些好處，但在重構(gòu)期間會有一些顯而易見的好處，比如可以很容易地發(fā)現(xiàn)細微的改變。通過將域聲明成公共的或是不可變的，就能夠直接在代碼中訪問它們，無需擔(dān)心不小心更改它們的情況發(fā)生。

一開始的時候，使用不可變域似乎有些不自然，如果您聽過 憤怒的猴子 這個故事的話，就會知道這種不同其實是有好處的：您還不習(xí)慣于處理 Java 中的不可變類，這看起來像是一種新的類型，如清單 5 中所示：

清單 5. Address 類的單元測試

@Test (expected = UnsupportedOperationException.class)public void address_access_to_fields_but_enforces_immutability() {Address a = new Address(streets("201 E Randolph St", "Ste 25"), "Chicago", "IL", "60601");assertEquals("Chicago", a.city);assertEquals("IL", a.state);assertEquals("60601", a.zip);assertEquals("201 E Randolph St", a.getStreets().get(0));assertEquals("Ste 25", a.getStreets().get(1));// compiler disallows//a.city = "New York";a.getStreets().clear();}

對公有不可變域的訪問避免了一系列 getXXX() 調(diào)用所帶來的可見開銷，還要注意的是，編譯器不會允許您給這些原始類型中的任一個賦值，如果您試著調(diào)用 street 集合上的可變方法的話，您就會收到一個 UnsupportedOperationException （方式是在測試的頂部捕獲）。這種代碼風(fēng)格的使用從視覺上給出了一種強烈的指示：該類是一個不可變類。

不利的方面

這種更清晰的語法的一個可能缺點是需要花一些精力來學(xué)習(xí)這種新的編程技法，不過我覺得這樣做是值得的：這一過程會促進您在創(chuàng)建類的時候想著不變性，因為類的風(fēng)格是如此明顯不同，并且刪除了不必要的樣板代碼。不過 Java 中的這種代碼風(fēng)格也有著一些缺點（說句公道話，Java 的直接目的從來都不是為了迎合不變性）：

1.正如 Glenn Vanderburg 向我指出的那樣，最大的缺點是這一風(fēng)格違反了 Bertrand Meyer（Eiffel 編程語言的創(chuàng)建者）所說的統(tǒng)一訪問原則 (Uniform Access Principle)：模塊提供的所有服務(wù)應(yīng)該是通過一種統(tǒng)一的標記法來使用的，無論服務(wù)是通過存儲還是通過計算來實現(xiàn)的，都不能違背這種標記法。換句話說，對域的訪問不應(yīng)該暴露出該域是一個域還是一個返回值的方法。Address 類的 getStreets() 方法與其他域沒有保持統(tǒng)一。這一問題在 Java 中不可能得到真正的解決；但在其他的一些 JVM 語言中已經(jīng)通過實現(xiàn)不變性解決了這個問題。

2.一些重度依賴反射的框架無法使用這種編程技法來工作，因為他們需要一個默認的構(gòu)造函數(shù)。

3.因為您是創(chuàng)建新的對象而不是改變原有的對象，因此有著大量更新的系統(tǒng)可能就會導(dǎo)致以為垃圾收集而帶來的效率低下。Clojure 一類的語言內(nèi)置了一些工具，通過使用不可變引用將這種情況變得更高效一些，這是這些語言中的默認做法。

Groovy 中的不可變性

可以使用 Groovy 來構(gòu)建公共的不可變域版本的 Address 類，這帶來的是一種非常清晰的實現(xiàn)，如清單 6 所示：

清單 6. 使用 Groovy 編寫的不可變的 Address 類

class Address {def public final List<String> streets;def public final city;def public final state;def public final zip;def Address(streets, city, state, zip) {this.streets = streets;this.city = city;this.state = state;this.zip = zip;}def getStreets() {Collections.unmodifiableList(streets);}}

一如既往，Groovy 需要的樣板代碼要比 Java 的少，并且還提供了其他方面的一些好處。因為 Groovy 允許您使用熟悉的 get/set 語法來創(chuàng)建屬性，因此您可以為對象引用創(chuàng)建真正受保護的屬性?？紤]一下清單 7 中給出的單元測試：

清單 7. 單元測試展示了 Groovy 中的統(tǒng)一訪問

class AddressTest {@Test (expected = ReadOnlyPropertyException.class)void address_primitives_immutability() {Address a = new Address(["201 E Randolph St", "25th Floor"], "Chicago", "IL", "60601")assertEquals "Chicago", a.citya.city = "New York"}@Test (expected=UnsupportedOperationException.class)void address_list_references() {Address a = new Address(["201 E Randolph St", "25th Floor"], "Chicago", "IL", "60601")assertEquals "201 E Randolph St", a.streets[0]assertEquals "25th Floor", a.streets[1]a.streets[0] = "404 W Randoph St"}}

可以注意到，在這兩個用例中，測試會在拋出異常時終止，這是因為有語句違反了不可變性合約。不過在 清單 7 中，streets 屬性看起來就像是原始類型，但實際上它是用自己的 getStreets() 方法來保護其自身。

Groovy 的 @Immutable 注釋

本文章系列所持的一個基本宗旨就是，函數(shù)式語言應(yīng)該為您處理更多低層面的細節(jié)。一個很好的例子就是 Groovy 的 1.7 版本增加了 @Immutable 注解，該注解使得 清單 6 中的編碼方式變得不再重要了。清單 8 給出了一個使用了該注解的 Client 類：

清單 8. 不可變的 Client 類

@Immutableclass Client {String name, city, state, zipString[] streets}

因為用到了 @Immutable 注解，該類具有以下一些特點：

它是最終的。  屬性自動擁有了私有的、合成了 get 方法的域。  任何更新屬性的企圖都會導(dǎo)致拋出 ReadOnlyPropertyException 異常。  Groovy 既創(chuàng)建了有序的構(gòu)造函數(shù)，又創(chuàng)建了基于映射的構(gòu)造函數(shù)。  集合類被封裝在適當(dāng)?shù)陌b器中，數(shù)組（及其他可克隆的對象）被克隆。  自動生成默認的 equals、hashcode 和 toString 方法。

一句注解提供了這么多的作用！它的行為也正如您所期望的那樣，如清單 9 所示：

清單 9. @Immutable 注解正確地處理了預(yù)期的情況

@Test (expected = ReadOnlyPropertyException)void client_object_references_protected() {def c = new Client([streets: ["201 E Randolph St", "Ste 25"]])c.streets = new ArrayList();}@Test (expected = UnsupportedOperationException)void client_reference_contents_protected() {def c = new Client ([streets: ["201 E Randolph St", "Ste 25"]])c.streets[0] = "525 Broadway St"}@Testvoid equality() {def d = new Client([name: "ACME", city:"Chicago", state:"IL",zip:"60601",streets: ["201 E Randolph St", "Ste 25"]])def c = new Client([name: "ACME", city:"Chicago", state:"IL",zip:"60601",streets: ["201 E Randolph St", "Ste 25"]])assertEquals(c, d)assertEquals(c.hashCode(), d.hashCode())assertFalse(c.is(d))}

試圖重置對象引用的操作會導(dǎo)致拋出 ReadOnlyPropertyException 異常。如果試圖改變其中的一個被封裝起來的對象引用所指向的內(nèi)容，則會導(dǎo)致拋出 UnsupportedOperationException 異常。該注解還創(chuàng)建了適當(dāng)?shù)?equals 和 hashcode 方法，如最后一個測試中所示，對象內(nèi)容是相同的，但它們沒有指向同一個引用。

當(dāng)然，Scala 和 Clojure 都支持并促進了不變性，且都有著清晰的不變性語法，接下來的文章會不時地談到它們所帶來的影響。

不變性的好處

在像函數(shù)式編程者那樣思考的方法列表中，維護不變性處于列表的較高位置。盡管用 Java 來構(gòu)建不可變對象前期帶來了更多的復(fù)雜性，但由這種抽象帶來的后期簡易性很容易補償前面所做的工作。

不可變類擯棄了 Java 中許多一些典型的令人煩心的缺陷。轉(zhuǎn)向函數(shù)式編程的好處之一是讓人們意識到，測試的存在是為了檢查代碼中成功發(fā)生的轉(zhuǎn)變。換句話說，測試的真正目的是驗證改變，改變越多，就需要越多的測試來確保您的做法是正確的。如果您通過嚴格限制改變來隔離變化的發(fā)生，那么您為錯誤的發(fā)生制造了更小的空間，需要測試的地方也就更少。因為變化只會發(fā)生構(gòu)造函數(shù)中，因此不可變類會將編寫單元測試變成了一件微不足道的事情。

您不需要使用復(fù)制構(gòu)造函數(shù)，并且永遠也不需要大汗淋漓地去實現(xiàn) clone() 方法的那些令人慘不忍睹的細節(jié)。將不可變對象用作 Map 或是 Set 中的鍵值是也一種很不錯的選擇；因為 Java 的字典集合中的鍵不能更改值，因此，在將不可變對象用作鍵時，它是非常好用的鍵。

不可變對象也是自動線程安全的，不存在同步問題。它們也不可能因為異常的發(fā)生而處于一種未知的或是無法預(yù)期的狀態(tài)中。因為所有的初始化都發(fā)生在構(gòu)造階段，這在 Java 中是一個原子過程，所有異常都發(fā)生在擁有對象實例之前。Joshua Bloch 將這稱作失敗的原子性：在已經(jīng)構(gòu)建對象后，這種基于不可變性的成功或是失敗就是一錘定音的了

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。