幾周前，我寫了關于Java 8 lambda的介紹 。 在本簡介中，我解釋了什么是lambda以及如何將它們與Java 8中也引入的新Stream API結合使用。

Stream API為集合提供了更實用的接口。 此接口在很大程度上取決于lambda。 但是，lambda不僅具有改進的收集處理能力，還具有更多優勢

Lambda為您提供了構建更流暢的API的機會。 為了說明這一點，作為示例，我喜歡使用UserStore ，它有助于使用數據庫獲取和保存用戶。 它的公共API通常如下所示。

public interface UserStore {User find(Long id);List<User> findByLastname(String lastname);List<User> findByCompany(String company);.. }

findBy方法的列表通常比我在此處包括的兩個方法更長。 隨著系統的發展，可能還會有其他人。 盡管可行，但實際上所有這些方法都可以完成相同的事情。 他們返回具有匹配特定值的屬性的所有用戶。

一些框架提供了解決此問題的方法。 如果您使用過Hibernate，您可能會知道它們通過findByExample提供了解決方法，其中您提供了User作為示例對象，提供了查詢的屬性和值。 使用此示例對象中設置的任何值進行查詢，而從查詢中排除任何為null字段。 您可以稍微調整一下這種行為，但是這種方法存在許多問題。 考慮默認值，必填字段（即無法填寫的字段）
null ）和不變性。 iBatis，MyBatis以及Spring Data使用代碼生成來節省您實現所有這些方法的時間，而使API充滿了findBy方法列表。

這些變通辦法可能會走很長一段路，但是它們確實留下了自己的特定問題。 另一種方法是使用lambda。

Lambda可以幫助我們將查詢部分與過濾器規范分離。 讓我們將findBy函數更改為接受lambda的單個函數。

public interface UserStore {User find(Long id);List<User> findBy(Predicate<User> p); }

那是一個更好的API。 顯然，謂詞檢查User對象有點天真。 您通常希望使用數據庫查詢進行過濾。 盡管如此，它仍然很好地滿足了本示例的目的，您可以嘗試使用自己的lambda來使用數據庫查詢進行過濾。 [注意： Predicate是Java 8附帶的，位于java.util.function包中。

至少在以前的API中，這些謂詞被捆綁在一個地方之前，您可能會生氣，我們仍然可以捆綁（通用）謂詞。 例如，通過創建一個包含它們的實用程序類UserPredicates 。

public final class UserPredicates {public static Predicate<User> lastname(String matcher) {return candidate -> matcher.equals(candidate.getLastname());} }

使用新的UserStore API變得非常簡單。

static import UserPredicates.lastname;userStore.findBy(lastname("<lastname>");

不過， UserStore中還有一件事確實讓我感到困擾。 find(id)函數返回一個用戶。 但是，如果沒有這樣的用戶呢？

可選的

為了對此進行改進，我們可以（并且應該）查看Java 8的另一個新功能，Optional。 這是monad的Java實現。 它看起來很像Scala的Option 。

使用Optional我們可以更好地表示一個函數可以返回一個值，但不一定返回一個值，并防止使用null 。 在我們的find(id)示例中，返回Optional明確表示我們可能找到具有所請求ID的用戶，但可能不存在這樣的用戶。

public interface UserStore {Optional<User> find(Long id);List<User> findBy(Predicate p); }

該API現在不僅記錄了您可能會獲得用戶的事實，而且從未返回null 。 我認為永不返回null的API更加安全。 有一天，一個新的程序員可能沒有意識到find可以返回null并且結果是一個null指針異常。 只是希望團隊能夠在生產之前就抓住它。 只要不使用null ，就很容易防止空指針異常。

我們可以使用Optional上的函數從用戶那里獲取一個值（如果有的話），或者從一個默認值中獲取一個值。 例如，為了安全地獲取用戶的姓氏，我們編寫以下內容。

Optional<User> user = userStore.find(id); String lastname = user.map(User::getLastname).orElse("");

這段代碼表達力很強，不需要太多解釋。 如果有用戶，請獲取其姓氏。 否則，獲取一個空字符串。

如果我們需要向用戶發送密碼重置電子郵件（如果找到）怎么辦？

Optional<User> user = userStore.find(id); user.ifPresent(passwordReset::send);

如果找到用戶，則發送密碼重置，否則什么也沒有發生。

由于Java不像其他可能提供的其他語言（例如Haskell，Clojure和Scala）那樣支持解構，因此我們僅限于Optional的功能。 這使得Optional比任何一種其他語言的等效功能都弱。

建造者

當然，不僅存儲庫的API都可以從lambda中受益。 Optional也是受益于lambda的API的一個很好的示例。 就我個人而言，我還發現lambda特別有用，可以代替過去的過往建造者。 通常不通過將特定的構建器傳遞給函數，而是通過從函數中生成一個構建器來改善去耦。 讓我向您展示一個示例，用于發送電子郵件以闡明該想法。

public interface Mailer {void sendTextMessage(TextMessageBuilder message);void sendMimeMessage(MimeMessageBuilder message); }

要使用Mailer我們需要將特定的構建器傳遞給它。 這些構建器具有通用的界面，但是它們構建的消息類型不同。 Mailer具有不同的方法，因為它必須根據所使用的類型添加不同的信息。 因此，任何客戶端代碼都緊密耦合以傳遞正確的構建器。

您可能會懷疑，這是lambda有用的地方。 Mailer函數可以創建所需的生成器并將其產生給lambda，而不是要求客戶端創建生成器并將其傳遞給客戶端。

public interface Mailer {void sendTextMessage(MessageConfigurator configurator);void sendMimeMessage(MessageConfigurator configurator);@FunctionalInterfaceinterface MessageConfigurator {MessageBuilder configure(MessageBuilder message);} }

要使用Mailer我們要做的就是提供一個lambda來構建消息。

mailer.sendTextMessage(message ->message.from(sender).to(recipients).subject("APIs").body("Lambdas can make for more fluent and stable APIs") );

API現在更加穩定。 客戶端代碼與特定構建器中的任何更改都脫鉤，并且只要構建器上的功能保持兼容就不會中斷。

正如示例幫助我展示的那樣，lambda可以幫助您構建更流暢和穩定的API，這些API更具意圖。 這些API不需要太多的文檔供其他程序員使用，因為實際上很難使它們弄錯。 作為一般準則，我更喜歡清晰明了的代碼而不是文檔。 修復，不記錄。

當然，我在本文中僅顯示了一些示例。 Lambda不僅適用于此處的示例，而且適用范圍更廣。 我希望本文能為您提供一些有關lambda可以幫助您的新見解，并希望您能想到它們如何改善您的代碼。

參考： Software Craft博客上的JCG合作伙伴 Bart Bakker 提供的Fluent和Stable API的Lambda 。

翻譯自: https://www.javacodegeeks.com/2013/11/lambdas-for-fluent-and-stable-apis.html

總結

以上是生活随笔為你收集整理的流畅和稳定的API的Lambda的全部內容，希望文章能夠幫你解決所遇到的問題。

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