Java 8引入的Optional類一直是該語言版本引入的最具爭議的功能之一。 盡管我喜歡這個新的Java類的東西比不喜歡的東西多，但在Java方法中將其用作return類型時，需要考慮一些事情。 我將在本文中討論其中的一些問題，但不會討論有關是否應該將Optional限制為用作返回類型的爭論 。 我還假定Optional僅在期望在某些情況下該方法不應該返回任何值時才用作返回類型。 最后，這些觀察結果適用于其他類型，并且也直接在Java中使用null ，但是Optional強調并具體說明了這些觀察結果。

單一收益與多重收益

在一般的軟件開發社區和Java開發社區中，有一段時間一直在爭論（“ 宗教戰爭 ”）關于是否應該編寫方法僅return一次（在本次討論中不計入拋出異常 ）的爭論。 一方面， Yegor Bugayenko認為“ 許多返回語句在OOP中不是一個好主意 ”， Tom Dalling認為“ 從函數中獲得一個退出點（返回）是一件好事 ”，而且許多人認為經常有多個return語句表示需要重構該方法 。 另一方面， 布魯斯·埃克爾（Bruce Eckel）認為 ，多個return語句可使代碼更“清晰”， 泰勒·高鐵 （ Taylor Gautier）認為，“ 格言（Maxim） ”“一種方法應該只有一個出口點”“不會再錯了”， 彼得Ritchie認為， 嚴格遵守單出口，如今會導致“面向對象的語言”中的“可讀性較低”的代碼，而Mark Levison概述了“ 一些我不喜歡單出口論點的原因 ?！?

Nicolai Parlog在“ 多重返回語句 ”一文中 ，介紹了方法僅返回一次的想法的歷史以及需要考慮的事項。 他包括“多重收益表的情況”一節，其中概述了“一種方法可以從多個收益表中獲利的幾種情況?！?我最好的猜測是，許多開發商覺得我做的方式，這是“這取決于”決定一個特定的方法是否應該只有一個的時候return陳述或應該有一個以上的return聲明。

當我開始更頻繁地將Java 8的Optional用于我的方法的返回類型時，我發現在確定是從方法中返回一次還是多次時，還需要考慮使用Optional作為返回類型。

在聲明Java方法返回Optional ，重要的是要充分理解這并不妨礙編寫此方法的開發人員返回null 。 返回的Optional是引用類型，并且與任何引用類型一樣，可以為null 。 至關重要的是，開發人員編寫返回Optional的方法時， 切勿讓該方法返回null [通常應返回Optional.empty（）來代替]。 我將用兩句話來重申這一點：

• 第三版 ， 有效Java中項目＃55中突出顯示的句子：“ 切勿從Optional -returning方法返回空值。 “
• 斯圖爾特·馬克（Stuart Marks）使用Optional 的＃1規則 ，“永遠，永遠不要對Optional變量或返回值使用null。”

一個方法中針對多個return語句的參數之一是，它使得識別每種情況下返回的內容變得更加困難（查找所有可能的返回方案）。 使用Optional作為返回類型的一個具體示例說明了這一點。 一個人要確保在某些情況下自己的方法不會返回null ，而在其他情況下則要確保返回Optional實例。 編譯器當然不會在每種情況下返回哪個值。

解決此問題的一種方法是只從方法中返回一次，然后開發人員編寫代碼，而開發人員查看代碼則可以輕松地確保不返回null 。 這些開發人員將只需要查找Optional.of（T）調用， Optional.ofNullable（T）調用或Optional.empty（）調用。

在方法中使用基礎數據類型的局部變量

當在返回點實例化Optional時，這種避免意外返回null而不是空Optional最有效。 換句話說，我發現最好在整個方法中使用Optional包裝的類型，然后在最后可能的時候將其放在Optional中。 下一個代碼清單提供了這些荒謬的瑣碎示例。

聲明最終以可選方式返回的局部變量的示例

/*** Provides the middle name if it exists.** @return Middle name if it exists or empty if it doesn't exist.*/ public Optional<String> determineMiddleName1() {String middleName;// Do whatever logic is necessaryreturn Optional.ofNullable(middleName); }/*** Provides the middle name if it exists.** @return Middle name if it exists or empty if it doesn't exist.*/ public Optional<String> determineMiddleName2() {Optional<String> middleName;// Do whatever logic is necessaryreturn middleName; }

在上面的代碼中， determineMiddleName 1 ()方法與基礎類型的局部變量一起使用。 通常，這比Optional更容易設置/填充，并且在末尾使用Optional.isNullable()可確保即使是null MiddleName也將作為“空”的Optional而不是null 。

上面的代碼中的defineMiddleName determineMiddleName 2 ()方法聲明其局部變量，該局部變量最終將作為Optional<String>返回，然后在該方法末尾返回該引用。

避免局部變量的“默認”初始化

在上面編寫方法defineMiddleName determineMiddleName 2 () ，編譯器將幫助確保將局部變量“ middleName”設置為某物（即使該“ something”為null ），但開發人員已選擇將其“ middleName”變量初始化為null開頭，編譯器將不會有任何問題。 如果由于某種原因需要初始化局部變量，最好將其初始化為Optional.empty()而不是null 。 如果開發人員選擇使用Optional.empty()初始化該變量，那么第二個示例仍然有可能在該方法的后面將本地變量“重置”為null 。

該討論使我對Java中將Optional用作方法返回類型有三點看法。

單個return或多個return s對意外返回null而不是“空”或其他非null的可能性的影響在確定單個返回或多個返回是否最有意義時應考慮Optional引用。

通過在整個方法中處理基礎類型并僅在最新時刻（通常在return ）實例化返回的Optional ，通常更容易確保返回Optional引用而不是返回null 。

最終將要從方法返回的Optional類型的局部變量，即使“已知”將適當地重新設置，也絕不應最初將其分配為null 。 最好根本不要定義它，以便編譯器將確保需要在代碼流的每個“分支”中對其進行設置。 最起碼，如果是進行初始化，類型的那個局部變量Optional應該被初始化為Optional.empty()而不是向null 。

這些觀察可以合并。 例如，當確定某個方法應具有多個返回（例如實現guard子句 ）時，可以在每次返回時返回適當的非null Optional引用，并且直到需要時才初始化局部變量（通過警衛）。 下一個可笑的例子說明了這一點。

避免使用多個返回語句返回空值的示例

public Optional<String> getGuardedData(final String input) {if (input == null){return Optional.empty();}String data;// Do whatever logic is necessaryreturn Optional.ofNullable(data); }

我發現Optional類在正確用作方法返回類型時，由于它的流利程度更高，可以使客戶端的代碼更具可讀性。 但是，要獲得其最大值，必須遵循紀律應用Optional ，以便代碼的客戶可以期望返回的Optional永遠不會為null 。 這篇文章研究了一些注意事項，可以幫助確保從不會將自已聲明為return Optional的方法返回null 。 沒有信任，該方法不會返回null ，使用Optional的返回類型只能使事情變得更糟，因為它迫使客戶端的非第一次檢查null Optional調用上的方法之一，之前Optional 。 這使得調用代碼不太流暢 。

翻譯自: https://www.javacodegeeks.com/2018/01/considerations-returning-java-8s-optional-method.html

總結

以上是生活随笔為你收集整理的从方法返回Java 8的可选项时的注意事项的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。