本文最初是我們使用RxJava進(jìn)行反應(yīng)式編程的附錄。 但是，盡管與反應(yīng)式編程非常相關(guān)，但對monad的介紹卻不太適合。 因此，我決定將其取出并作為博客文章單獨(dú)發(fā)布。 我知道，“ 我自己的，對單子的一半正確和半完全的解釋 ”是編程博客上的新“ Hello，world ”。 然而，本文從Java數(shù)據(jù)結(jié)構(gòu)和庫的特定角度研究了函子和monad。 因此，我認(rèn)為值得分享。

RxJava的設(shè)計(jì)和構(gòu)建基于非常基本的概念，例如函子 ， monoid和monad 。 盡管Rx最初是為命令式C＃語言建模的，并且我們正在學(xué)習(xí)RxJava，并在類似的命令式語言上工作，但該庫還是源于函數(shù)式編程。 在意識(shí)到RxJava API的緊湊性之后，您應(yīng)該不會(huì)感到驚訝。 幾乎只有少數(shù)幾個(gè)核心類，通常是不可變的，并且所有內(nèi)容都主要由純函數(shù)組成。

隨著函數(shù)式編程（或函數(shù)式樣式）的最新興起（通常以Scala或Clojure等現(xiàn)代語言表示），monads成為了廣泛討論的話題。 他們周圍有很多民間傳說：

一元論是endofunctors類別中的一個(gè)monoid，這是什么問題？
詹姆斯·伊里

該monad的詛咒是，一旦您獲得了頓悟，一旦您理解了“哦，就是這樣”，您就失去了向任何人解釋它的能力。
道格拉斯·克羅克福德

絕大多數(shù)程序員，尤其是那些沒有函數(shù)式編程背景的程序員，都傾向于認(rèn)為monad是某種神秘的計(jì)算機(jī)科學(xué)概念，因此從理論上講，它對他們的編程事業(yè)無濟(jì)于事。 這種消極的觀點(diǎn)可以歸因于數(shù)十篇文章和博客文章過于抽象或過于狹窄。 但是事實(shí)證明，甚至在標(biāo)準(zhǔn)Java庫中也存在monad，特別是從Java Development Kit（JDK）8開始（以后會(huì)有更多介紹）。 絕對妙不可言的是，一旦您第一次了解monad，突然之間就會(huì)有幾個(gè)完全不相同的目的無關(guān)的類和抽象變得熟悉。

Monad泛化了各種看似獨(dú)立的概念，因此學(xué)習(xí)Monad的另一種化身只需很少的時(shí)間。 例如，您不必學(xué)習(xí)CompletableFuture在Java 8中的工作方式，一旦意識(shí)到它是monad，就可以精確地知道它是如何工作的，并且可以從其語義中得到什么。 然后您會(huì)聽說RxJava聽起來有很大不同，但是由于Observable是monad，因此沒有太多可添加的。 您已經(jīng)不知不覺中已經(jīng)遇到過許多其他的單子示例。 因此，即使您實(shí)際上沒有使用RxJava，本節(jié)也將是有用的復(fù)習(xí)。

函子

在解釋什么是monad之前，讓我們研究一個(gè)稱為functor的簡單結(jié)構(gòu)。 函子是封裝某些值的類型化數(shù)據(jù)結(jié)構(gòu)。 從語法的角度來看，函子是具有以下API的容器：

import java.util.function.Function;interface Functor<T> {<R> Functor<R> map(Function<T, R> f);}

但是僅僅語法是不足以了解什么是函子。 functor提供的唯一操作是帶有函數(shù)f map() 。 該函數(shù)接收框內(nèi)的任何內(nèi)容，對其進(jìn)行轉(zhuǎn)換并將結(jié)果按原樣包裝到另一個(gè)函子中。 請仔細(xì)閱讀。 Functor<T>始終是不可變的容器，因此map不會(huì)使執(zhí)行該操作的原始對象發(fā)生突變。 相反，它返回結(jié)果（或結(jié)果-是患者）包裹在一個(gè)品牌新的算符，可能的不同類型R 此外，在應(yīng)用身份函數(shù)（即map(x -> x)時(shí)，函子不應(yīng)執(zhí)行任何操作。 這種模式應(yīng)始終返回相同的函子或相等的實(shí)例。

通常將Functor<T>與一個(gè)保存T實(shí)例進(jìn)行比較，在該實(shí)例中，與該值交互的唯一方法是對其進(jìn)行轉(zhuǎn)換。 但是，沒有從函子解開或逃逸的慣用方式。 值始終在函子的上下文內(nèi)。 函子為什么有用？ 它們使用一個(gè)統(tǒng)一的，適用于所有規(guī)范的API概括了多個(gè)通用習(xí)語，如集合，promise，Optionals等。 讓我介紹幾個(gè)函子，以使您更流暢地使用此API：

interface Functor<T,F extends Functor<?,?>> {<R> F map(Function<T,R> f); }class Identity<T> implements Functor<T,Identity<?>> {private final T value;Identity(T value) { this.value = value; }public <R> Identity<R> map(Function<T,R> f) {final R result = f.apply(value);return new Identity<>(result);}}

要使Identity編譯，需要額外的F類型參數(shù)。 在前面的示例中，您看到的是最簡單的函子，僅包含一個(gè)值。 您只能用map方法內(nèi)部的值對其進(jìn)行轉(zhuǎn)換，但是無法提取它。 這被認(rèn)為超出了純函子的范圍。 與函子進(jìn)行交互的唯一方法是應(yīng)用類型安全的轉(zhuǎn)換序列：

Identity<String> idString = new Identity<>("abc"); Identity<Integer> idInt = idString.map(String::length);

或流利地，就像您編寫函數(shù)一樣：

Identity<byte[]> idBytes = new Identity<>(customer).map(Customer::getAddress).map(Address::street).map((String s) -> s.substring(0, 3)).map(String::toLowerCase).map(String::getBytes);

從這個(gè)角度來看，在函子上的映射與調(diào)用鏈?zhǔn)胶瘮?shù)沒有太大不同：

byte[] bytes = customer.getAddress().street().substring(0, 3).toLowerCase().getBytes();

您為什么還要打擾這樣冗長的包裝，不僅不提供任何附加值，而且也不能提取內(nèi)容？ 好吧，事實(shí)證明您可以使用此原始函子抽象對其他幾個(gè)概念建模。 例如，從Java 8開始的java.util.Optional<T>是帶有map()方法的函子。 讓我們從頭開始實(shí)現(xiàn)它：

class FOptional<T> implements Functor<T,FOptional<?>> {private final T valueOrNull;private FOptional(T valueOrNull) {this.valueOrNull = valueOrNull;}public <R> FOptional<R> map(Function<T,R> f) {if (valueOrNull == null)return empty();elsereturn of(f.apply(valueOrNull));}public static <T> FOptional<T> of(T a) {return new FOptional<T>(a);}public static <T> FOptional<T> empty() {return new FOptional<T>(null);}}

現(xiàn)在變得有趣了。 FOptional<T>函子可以保存一個(gè)值，但也可以為空。 這是一種對null進(jìn)行編碼的類型安全的方法。 構(gòu)造FOptional方法有兩種：通過提供值或創(chuàng)建empty()實(shí)例。 在這兩種情況下，就像Identity ， FOptional是不可變的，我們只能從內(nèi)部與值交互。 FOptional不同之FOptional在于，如果轉(zhuǎn)換函數(shù)f為空，則它可能不會(huì)應(yīng)用于任何值。 這意味著函子可能不必完全封裝類型T一個(gè)值。 它也可以包裝任意數(shù)量的值，就像List …functor：

import com.google.common.collect.ImmutableList;class FList<T> implements Functor<T, FList<?>> {private final ImmutableList<T> list;FList(Iterable<T> value) {this.list = ImmutableList.copyOf(value);}@Overridepublic <R> FList<?> map(Function<T, R> f) {ArrayList<R> result = new ArrayList<R>(list.size());for (T t : list) {result.add(f.apply(t));}return new FList<>(result);} }

API保持不變：在轉(zhuǎn)換T -> R使用函子，但是行為卻大不相同。 現(xiàn)在，我們對FList每個(gè)項(xiàng)目進(jìn)行FList ，以聲明方式轉(zhuǎn)換整個(gè)列表。 因此，如果您有一個(gè)customers列表，并且想要他們的街道列表，則非常簡單：

import static java.util.Arrays.asList;FList<Customer> customers = new FList<>(asList(cust1, cust2));FList<String> streets = customers.map(Customer::getAddress).map(Address::street);

這不再像說customers.getAddress().street()那樣簡單，您不能在一組客戶上調(diào)用getAddress() ，必須在每個(gè)單獨(dú)的客戶上調(diào)用getAddress() ，然后將其放回一個(gè)集合中。 順便說一句，Groovy發(fā)現(xiàn)這種模式非常普遍，以至于實(shí)際上有一個(gè)語法糖： customer*.getAddress()*.street() 。 該運(yùn)算符稱為散點(diǎn)圖，實(shí)際上是變相的map 。 也許您想知道為什么我要在map list手動(dòng)遍歷list而不是使用Java 8中的Stream ： list.stream().map(f).collect(toList()) ？ 這會(huì)響嗎？ 如果我告訴您Java java.util.stream.Stream<T>也是一個(gè)函子怎么辦？ 順便說一句，一個(gè)單子？

現(xiàn)在，您應(yīng)該看到函子的第一個(gè)好處–它們抽象了內(nèi)部表示形式，并為各種數(shù)據(jù)結(jié)構(gòu)提供了一致且易于使用的API。 作為最后一個(gè)示例，讓我介紹類似于Future promise函數(shù)。 Promise “承諾”某一天將提供一個(gè)值。 它尚未出現(xiàn)，可能是因?yàn)楫a(chǎn)生了一些后臺(tái)計(jì)算，或者我們正在等待外部事件。 但是它將在將來出現(xiàn)。 完成Promise<T>的機(jī)制并不有趣，但是函子的性質(zhì)是：

Promise<Customer> customer = //... Promise<byte[]> bytes = customer.map(Customer::getAddress).map(Address::street).map((String s) -> s.substring(0, 3)).map(String::toLowerCase).map(String::getBytes);

看起來很熟悉？ 這就是重點(diǎn)！ Promise函子的實(shí)現(xiàn)超出了本文的范圍，甚至不重要。 不用說，我們非常接近從Java 8實(shí)現(xiàn)CompletableFuture ，并且?guī)缀鯊腞xJava中發(fā)現(xiàn)了Observable 。 但是回到函子。 Promise<Customer>尚未持有Customer的值。 它有望在將來具有這種價(jià)值。 但是我們?nèi)匀豢梢韵袷褂肍Optional和FList一樣映射此類函子–語法和語義完全相同。 行為遵循函子表示的內(nèi)容。 調(diào)用customer.map(Customer::getAddress)產(chǎn)生Promise<Address> ，這表示map是非阻塞的。 customer.map() 不會(huì)等待基礎(chǔ)的customer承諾完成。 相反，它返回另一個(gè)不同類型的承諾。 當(dāng)上游承諾完成時(shí)，下游承諾應(yīng)用傳遞給map()的函數(shù)并將結(jié)果傳遞給下游。 突然，我們的函子使我們能夠以非阻塞方式流水線進(jìn)行異步計(jì)算。 但是您不必了解或?qū)W習(xí)-因?yàn)镻romise是函子，所以它必須遵循語法和法則。

函子還有許多其他很好的例子，例如以組合方式表示值或錯(cuò)誤。 但是現(xiàn)在是時(shí)候看看單子了。

從函子到單子

我假設(shè)您了解函子如何工作以及為什么它們是有用的抽象。 但是函子并不像人們期望的那樣普遍。 如果您的轉(zhuǎn)換函數(shù)（作為參數(shù)傳遞給map()那個(gè)）返回函子實(shí)例而不是簡單值，會(huì)發(fā)生什么？ 好吧，函子也只是一個(gè)值，所以沒有壞事發(fā)生。 將返回的所有內(nèi)容放回函子中，以便所有行為都保持一致。 但是，假設(shè)您有以下方便的方法來解析String ：

FOptional<Integer> tryParse(String s) {try {final int i = Integer.parseInt(s);return FOptional.of(i);} catch (NumberFormatException e) {return FOptional.empty();} }

例外是會(huì)影響類型系統(tǒng)和功能純度的副作用。 在純函數(shù)語言中，沒有例外的地方，畢竟我們從來沒有聽說過在數(shù)學(xué)課上拋出例外，對嗎？ 錯(cuò)誤和非法條件使用值和包裝器明確表示。 例如， tryParse()接受一個(gè)String但并不簡單地返回int或在運(yùn)行時(shí)靜默引發(fā)異常。 通過類型系統(tǒng)，我們明確告知tryParse()可能失敗，字符串格式錯(cuò)誤不會(huì)有任何異常或錯(cuò)誤。 此半故障由可選結(jié)果表示。 有趣的是，Java已經(jīng)檢查了必須聲明和處理的異常，因此從某種意義上講，Java在這方面比較純凈，它沒有隱藏副作用。 但是，無論好壞，在Java中通常不建議使用檢查異常，因此讓我們回到tryParse() 。 用已經(jīng)包裝在FOptional String組成tryParse似乎很有用：

FOptional<String> str = FOptional.of("42"); FOptional<FOptional<Integer>> num = str.map(this::tryParse);

這不足為奇。 如果tryParse()返回一個(gè)int您將得到FOptional<Integer> num ，但是由于map()函數(shù)返回FOptional<Integer>本身，因此它被包裝兩次，成為笨拙的FOptional<FOptional<Integer>> 。 請仔細(xì)查看類型，您必須了解為什么我們在這里得到這種雙重包裝。 除了看上去很恐怖之外，在函子中放一個(gè)函子會(huì)破壞構(gòu)圖和流暢的鏈接：

FOptional<Integer> num1 = //... FOptional<FOptional<Integer>> num2 = //...FOptional<Date> date1 = num1.map(t -> new Date(t));//doesn't compile! FOptional<Date> date2 = num2.map(t -> new Date(t));

在這里，我們嘗試通過將int轉(zhuǎn)換為+ Date +來映射FOptional的內(nèi)容。 具有Functor<Integer> int -> Date的功能，我們可以輕松地從Functor<Integer>為Functor<Date> ，我們知道它是如何工作的。 但是在num2情況下情況變得復(fù)雜。 num2.map()接收的輸入不再是int而是FOoption<Integer> ，顯然java.util.Date沒有這樣的構(gòu)造函數(shù)。 我們通過雙層包裹來破壞了函子。 但是，擁有一個(gè)返回函子而不是簡單值的函數(shù)非常普遍（例如tryParse() ），我們不能簡單地忽略這種要求。 一種方法是引入一種特殊的無參數(shù)join()方法，以“展平”嵌套函子：

FOptional<Integer> num3 = num2.join()

它可以工作，但是因?yàn)檫@種模式太普遍了，所以引入了一種名為flatMap()特殊方法。 flatMap()與map非常相似，但希望作為參數(shù)接收的函數(shù)返回函子-或monad是精確的：

interface Monad<T,M extends Monad<?,?>> extends Functor<T,M> {M flatMap(Function<T,M> f); }

我們僅得出結(jié)論， flatMap只是一種語法糖，可以實(shí)現(xiàn)更好的組合。 但是flatMap方法（在Haskell中通常稱為bind或>>= ）具有所有不同，因?yàn)樗试S以純函數(shù)式的形式構(gòu)成復(fù)雜的轉(zhuǎn)換。 如果FOptional是monad的實(shí)例，則解析突然可以按預(yù)期進(jìn)行：

FOptional<Integer> num = FOptional.of(42); FOptional<Integer> answer = num.flatMap(this::tryParse);

Monad不需要實(shí)現(xiàn)map ，可以輕松地在flatMap()之上實(shí)現(xiàn)它。 實(shí)際上， flatMap是實(shí)現(xiàn)全新轉(zhuǎn)換領(lǐng)域的基本運(yùn)算符。 顯然，就像函子一樣，語法順從性還不足以將某個(gè)類稱為monad， flatMap()運(yùn)算符必須遵循monad定律，但它們非常直觀，就像flatMap()與標(biāo)識(shí)的關(guān)聯(lián)性一樣。 后者要求m(x).flatMap(f)與持有值x任何monad和函數(shù)f f(x)相同。 我們不會(huì)深入研究monad理論，而是讓我們關(guān)注實(shí)際含義。 當(dāng)內(nèi)部結(jié)構(gòu)并非無關(guān)緊要時(shí)，Monad便會(huì)發(fā)光，例如Promise monad，它將在將來具有一定的價(jià)值。 您可以從類型系統(tǒng)中猜測Promise在以下程序中的表現(xiàn)嗎？ 首先，所有可能花費(fèi)一些時(shí)間才能完成的方法都會(huì)返回Promise ：

import java.time.DayOfWeek;Promise<Customer> loadCustomer(int id) {//... }Promise<Basket> readBasket(Customer customer) {//... }Promise<BigDecimal> calculateDiscount(Basket basket, DayOfWeek dow) {//... }

現(xiàn)在，我們可以將這些函數(shù)組合起來，就好像它們都是使用單子運(yùn)算符進(jìn)行了阻塞一樣：

Promise<BigDecimal> discount = loadCustomer(42).flatMap(this::readBasket).flatMap(b -> calculateDiscount(b, DayOfWeek.FRIDAY));

這變得很有趣。 flatMap()必須保留monadic類型，因?yàn)樗兄虚g對象都是Promise 。 這不僅僅是保持類型有序–前一個(gè)程序突然完全異步！ loadCustomer()返回Promise因此不會(huì)阻塞。 readBasket()接受Promise擁有（將要擁有的一切）并應(yīng)用返回另一個(gè)Promise的函數(shù)，依此類推。 基本上，我們建立了一個(gè)異步計(jì)算管道，其中后臺(tái)完成一個(gè)步驟會(huì)自動(dòng)觸發(fā)下一步。

探索

有兩個(gè)單子并將它們包含的值組合在一起是很常見的。 但是函子和monad都不允許直接訪問其內(nèi)部，這是不純的。 相反，我們必須謹(jǐn)慎地應(yīng)用轉(zhuǎn)換，而不能逃脫monad。 假設(shè)您有兩個(gè)單子，并且想要將它們合并

import java.time.LocalDate; import java.time.Month;Monad<Month> month = //... Monad<Integer> dayOfMonth = //...Monad<LocalDate> date = month.flatMap((Month m) ->dayOfMonth.map((int d) -> LocalDate.of(2016, m, d)));

請花點(diǎn)時(shí)間研究前面的偽代碼。 我沒有使用任何真正的monad實(shí)現(xiàn)（例如Promise或List來強(qiáng)調(diào)核心概念。 我們有兩個(gè)獨(dú)立的monad，一個(gè)是Month類型，另一個(gè)是Integer類型。 為了從中構(gòu)建LocalDate ，我們必須構(gòu)建一個(gè)嵌套的轉(zhuǎn)換，該轉(zhuǎn)換可以訪問兩個(gè)monad的內(nèi)部。 仔細(xì)研究這些類型，尤其要確保您了解為什么我們在一個(gè)地方使用flatMap在另一個(gè)地方使用map() 。 想想如果您還有第三個(gè)Monad<Year> ，那么您將如何構(gòu)造此代碼。 這種應(yīng)用兩個(gè)參數(shù)（在本例中為m和d ）的函數(shù)的模式非常普遍，以至于Haskell中有一個(gè)名為liftM2特殊輔助函數(shù)，該函數(shù)正是在map和flatMap之上實(shí)現(xiàn)了這種轉(zhuǎn)換。 在Java偽語法中，它看起來像這樣：

Monad<R> liftM2(Monad<T1> t1, Monad<T2> t2, BiFunction<T1, T2, R> fun) {return t1.flatMap((T1 tv1) ->t2.map((T2 tv2) -> fun.apply(tv1, tv2))); }

您不必為每個(gè)monad都實(shí)現(xiàn)此方法， flatMap()足夠了，而且它對所有monad都一致地起作用。 當(dāng)您考慮如何將其與各種monad一起使用時(shí)， liftM2非常有用。 例如listM2(list1, list2, function)將對list1和list2 （笛卡爾積）中的每對可能的項(xiàng)應(yīng)用function 。 另一方面，對于可選項(xiàng)，僅當(dāng)兩個(gè)可選項(xiàng)均為非空時(shí)，才應(yīng)用功能。 更好的是，對于Promise monad，當(dāng)兩個(gè)Promise都完成時(shí)，將異步執(zhí)行一個(gè)函數(shù)。 這意味著我們只是發(fā)明了一個(gè)簡單的同步機(jī)制（分叉聯(lián)接算法中的join() ，該同步機(jī)制包含兩個(gè)異步步驟。

我們可以輕松地在flatMap()之上構(gòu)建的另一個(gè)有用的運(yùn)算符是filter(Predicate<T>) ，該運(yùn)算符接收monad內(nèi)部的所有內(nèi)容，如果不符合某些謂詞，則將其完全丟棄。 在某種程度上，它與map相似，但不是1-to-1映射，而是1-to-0-or-1。 同樣， filter()對于每個(gè)monad具有相同的語義，但是取決于我們實(shí)際使用的monad，其功能相當(dāng)驚人。 顯然，它允許從列表中過濾掉某些元素：

FList<Customer> vips = customers.filter(c -> c.totalOrders > 1_000);

但是它也可以很好地工作，例如對于可選項(xiàng)目。 在這種情況下，如果可選內(nèi)容不符合某些條件，我們可以將非空可選內(nèi)容轉(zhuǎn)換為空值。 空的可選部分保持不變。

從單子列表到單子列表

另一個(gè)來自flatMap()有用運(yùn)算符是sequence() 。 您只需查看類型簽名即可輕松猜測其作用：

Monad<Iterable<T>> sequence(Iterable<Monad<T>> moands)

通常，我們有一堆相同類型的monad，而我們想要一個(gè)具有該類型列表的monad。 對您來說，這聽起來很抽象，但卻非常有用。 假設(shè)您想通過ID同時(shí)從數(shù)據(jù)庫中加載一些客戶，因此您多次對不同的ID使用loadCustomer(id)方法，每次調(diào)用都返回Promise<Customer> 。 現(xiàn)在，您有了Promise的列表，但是您真正想要的是客戶列表，例如要在Web瀏覽器中顯示的客戶列表。 sequence() （在RxJava中sequence()稱為concat()或merge() ，具體取決于用例）是為此目的而構(gòu)建的：

FList<Promise<Customer>> custPromises = FList.of(1, 2, 3).map(database::loadCustomer);Promise<FList<Customer>> customers = custPromises.sequence();customers.map((FList<Customer> c) -> ...);

通過為每個(gè)ID調(diào)用database.loadCustomer(id) ，我們可以在其上map一個(gè)表示客戶ID的FList<Integer> （您看到FList是一個(gè)FList函數(shù)是如何幫助的？） 這導(dǎo)致Promise的列表相當(dāng)不便。 sequence()節(jié)省了一天的時(shí)間，但再次重申，這不僅僅是語法糖。 前面的代碼是完全非阻塞的。 對于不同種類的monads， sequence()仍然有意義，但是在不同的計(jì)算上下文中。 例如，可以將FList<FOptional<T>>更改為FOptional<FList<T>> 。 順便說一句，您可以在flatMap()之上實(shí)現(xiàn)sequence() （就像map()一樣flatMap() 。

一般而言，這只是關(guān)于flatMap()和monad有用性的冰山一角。 盡管源于晦澀的類別理論，但即使在Java之類的面向?qū)ο蟮木幊陶Z言中，monad也被證明是極其有用的抽象。 能夠組成返回單子函數(shù)的函數(shù)非常有用，以至于數(shù)十個(gè)無關(guān)的類遵循單子行為。

而且，一旦將數(shù)據(jù)封裝在monad中，通常很難顯式地將其取出。 這種操作不是monad行為的一部分，并且經(jīng)常導(dǎo)致非慣用的代碼。 例如， Promise<T>上的Promise.get()可以從技術(shù)上返回T ，但只能通過阻塞來返回，而所有基于flatMap()運(yùn)算符都是非阻塞的。 另一個(gè)示例是FOptional.get() ，它可能會(huì)失敗，因?yàn)镕Optional可能為空。 即使FList.get(idx)從列表偷窺特定元素聽起來很別扭，因?yàn)槟憧梢蕴鎿Qfor與循環(huán)map()經(jīng)常。

我希望您現(xiàn)在了解為什么現(xiàn)在這些單子如此流行。 即使在像Java這樣的面向?qū)ο蟮恼Z言中，它們也是非常有用的抽象。

翻譯自: https://www.javacodegeeks.com/2016/06/functor-monad-examples-plain-java.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的纯Java中的Functor和Monad示例的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。