文字「M」の言葉、またはモナドはすでにここにあります

モナドに関する多くのミームと伝説があります。 すべての自尊心のあるプログラマーは、彼の機能的成熟の過程で、少なくとも1つのモナドに関するチュートリアルを作成する必要があると言われています-この神秘的な獣を飼いならすために、Haskell言語のウェブサイトで特別なタイムラインが実施されることさえ理由がないわけではありません。 経験豊富な開発者はモナドの呪いについても話します -彼らは、このモンスターの本質を理解している人は皆、見たものを説明する能力を完全に失うと言います。 このために、いくつかは カテゴリー理論で武装し 、他は宇宙服を着ていますが、どうやらモナドに到達する単一の方法はないようです。



実際、モナドの概念自体は直観的ではありません。なぜなら、適切なトレーニングと理論的な準備なしでは直感が到達できないような抽象化のレベルにあるからです。 しかし、それはとても重要ですか、他に方法はありませんか？ さらに、これらの不思議なモナドは、多くの疑いを持たないプログラマーを既に取り囲んでいます。 実際、よく見ると、標準ライブラリのドキュメンテーションでは「モナド」という単語はほとんど見つかりませんが、Java言語で既に存在していることがわかります。



そのため、このパターンの深い本質を理解せず、少なくとも私たちを取り巻く既存のAPIでのモナドの使用例を認識することを学ぶことが重要です。 具体的な例では、常に1,000を超える抽象化または比較が行われます。 この記事は、まさにそのようなアプローチに専念しています。 カテゴリ理論は存在せず、実際には理論はまったく存在しません。 コードから引き裂かれた実世界のオブジェクトとの比較はありません。 おなじみのAPIでモナドが既にどのように使用されているかの例をいくつか紹介し、読者にこのパターンの主な兆候をつかむ機会を提供するようにします。 基本的に、この記事ではJavaについて説明します。最後に、レガシー制限の世界から抜け出すために、Scalaについて少し触れます。

問題：潜在的な行方不明のオブジェクト

次のJavaコードの行を見てください。

return employee.getPerson().getAddress().getStreet();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテキストで正常にコンパイルすると仮定すると、経験豊富な目はここで深刻な問題に気づくでしょう-呼び出しチェーンに返されたオブジェクトのいずれかが存在しない可能性があり（メソッドはnullを返します）、このコードが実行されると無慈悲なNullPointerExceptionがスローされます 幸いなことに、次のように、この行をいつでも一連のチェックで囲むことができます。

 if (employee != null && employee.getPerson() != null && employee.getPerson().getAddress() != null) { return employee.getPerson().getAddress().getStreet(); } else { return "<>"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それ自体はあまり良く見えませんが、他のコードで作成するのはさらに悪いです。 そして最も重要なことは、少なくとも1つのチェックを忘れると、実行時に例外が発生する可能性があることです。 これは、オブジェクトの潜在的な不在に関する情報が何らかの形で固定されておらず、コンパイラがエラーから私たちを救うことがないためです。 しかし、結局のところ、従業員から人を、人から住所を、住所から番地を取得するという3つの単純な連続アクションを実行したかっただけです。 単純なタスクのように見えますが、コードは補助チェックで膨れ上がり、判読できなくなりました。



幸い、Java 8ではjava.util.Optionalタイプが導入されました。 多くの興味深い方法がありますが、これらについて説明します。

 public class Optional<T> { public static <T> Optional<T> ofNullable(T value) { } public<U> Optional<U> map(Function<? super T, ? extends U> mapper) { } public<U> Optional<U> flatMap(Function<? super T, Optional<U>> mapper) { } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Optionalは、1つの要素を含むか、何も含まないコンテナと見なすことができます。 このコンテナでmapメソッドを呼び出し、そこで匿名関数（ラムダ）またはメソッドへの参照を渡すと、mapはOptional内のオブジェクトにこの関数を適用し、結果を返して、Optionalでラップします。 オブジェクトが内部に表示されない場合、マップは単純に空のオプションコンテナーを返しますが、型パラメーターは異なります。



flatMapメソッドを使用すると、mapメソッドと同じことができますが、それ自体がOptionalを返す関数を受け入れます。これらの関数を使用した結果は、Optionalでさらにラップされず、二重のネストは回避されます。



このようなオプションインターフェイスを使用すると、たとえば次のように、呼び出しをチェーンで配置できます。

 return Optional.ofNullable(employee) .map(Employee::getPerson) .map(Person::getAddress) .map(Address::getStreet) .orElse("<>");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前の例よりも少しコンパクトに見えます。 しかし、プロはそれで終わりではありません。 まず、コードから無関係なすべての殻を削除しました-従業員オブジェクトでいくつかの簡単なアクションを実行し、コードに不要な補助コードなしでそれらを明示的に記述しました。 第二に、このチェーンのパスのどこかにヌル値がある場合、NPEがないことを確認できます-オプションはこれから私たちを救います。 第三に、結果のコンストラクトは式であり（前の例のifコンストラクトのようなアサーションではありません）、値を返すことを意味します。したがって、他のコードで作成する方がはるかに簡単です。



それでは、オプションタイプを使用して、オブジェクトの潜在的な不在の問題をどのように解決しましたか？

1. 問題はオブジェクトタイプ（オプションの<従業員>）で明確に示されました。
2. 彼らは、このタイプ内のすべての補助コード（オブジェクトの不在をチェックする）を隠しました。
3. 単純な一致アクションのセットを型に渡します。

ここで「アクションの一致」とは何を理解していますか？ 次に、Person :: getAddressメソッドが、前のEmployee :: getPersonメソッドの結果として受け取ったPerson型のオブジェクトを受け入れます。 さて、Address :: getStreetメソッドはそれぞれ、前のアクション（Person :: getAddressメソッドの呼び出し）の結果を受け入れます。



そして今、主なもの：Javaのオプションは、モナドパターンの実装にすぎません。

問題：反復

近年Javaに登場したすべての構文糖衣により、これはもはや問題ではないように思われます。 ただし、次のコードを見てください。

 List<String> employeeNames = new ArrayList<>(); for (Company company : companies) { for (Department department : company.getDepartments()) { for (Employee employee : department.getEmployees()) { employeeNames.add(employee.getName()); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、すべての部門とすべての企業のすべての従業員の名前を単一のリストに収集します。 原則として、コードの外観はそれほど悪くありませんが、employeeNamesリストを変更する手続き型のスタイルは、プログラマーの顔をしかめます。 さらに、コードは明らかに冗長ないくつかのネストされた反復サイクルで構成されています-それらの助けを借りてコレクション反復メカニズムを説明しますが、概してそれは私たちにとって興味深いものではありませんが、すべての企業のすべての部門からすべての人々を収集し、名前を取得したいだけです。



Java 8では、まったく新しいAPIが導入されました。これにより、コレクションの操作がより便利になります。 このAPIのメインインターフェースはjava.util.stream.Streamインターフェースです。このインターフェースには、とりわけ、前の例からおなじみのメソッドが含まれています。

 public interface Stream<T> extends BaseStream<T, Stream<T>> { <R> Stream<R> map(Function<? super T, ? extends R> mapper); <R> Stream<R> flatMap(Function<? super T, ? extends Stream<? extends R>> mapper); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、マップメソッドは、Optionalの場合のように、オブジェクトを入力として変換し、コレクションのすべての要素に適用し、受信した変換済みオブジェクトから次のStreamを返す関数を受け取ります。 flatMapメソッドは、それ自体がStreamを返す関数を受け入れ、変換中に受信したすべてのストリームを単一のStreamにマージします。



Streams APIを使用して、反復コードを次のように書き換えることができます。

 List<String> streamEmployeeNames = companies.stream() .flatMap(Company::getDepartmentsStream) .flatMap(Department::getEmployeesStream) .map(Employee::getName) .collect(toList());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、JavaのStreams APIの制限を回避するために少しごまかしました。残念ながら、既存のコレクションは置き換えられませんが、機能コレクションの完全な並列ユニバースであり、ストリーム（）メソッドのポータルです。 したがって、データ処理中に取得された各コレクションは、この宇宙でペンを実行する必要があります。 これを行うために、コレクションのゲッターをCompanyクラスとDepartmentクラスに追加し、それらをすぐにStreamオブジェクトに変換します。

 static class Company { private List<Department> departments; public Stream<Department> getDepartmentsStream() { return departments.stream(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

解決策は、よりコンパクトに見えてもそれほどではありませんが、その利点はこれだけではありません。 実際、これはコレクションを操作するための代替メカニズムであり、よりコンパクトで、タイプセーフで、構成可能であり、その利点はコードの量と複雑さが増すにつれて明らかになり始めます。



したがって、コレクションの要素に対する反復問題を解決するために使用されるアプローチは、すでによく知られているいくつかのステートメントの形式で再び定式化できます。

1. 問題は、オブジェクトタイプ（ストリーム<会社>）で明確に示されました。
2. 彼らはこの型の中にすべての補助コードを隠しました（要素を繰り返し、その上で渡された関数を呼び出します）。
3. このタイプのオブジェクトに一連の単純なマッチングアクションを渡しました。

要約すると、JavaのStreamインターフェースはモナドパターンの実装です。

問題：非同期コンピューティング

これまで述べてきたことから、モナドパターンはオブジェクトに対する何らかのラッパーの存在を暗示しているように見えるかもしれません。これらのオブジェクトには、これらのオブジェクトを変換する関数、およびこれらの使用に関連するすべての退屈で不要なコードをスローできます関数、潜在的なエラーの処理、バイパスメカニズム-ラッパー内の記述。 しかし実際には、モナドの適用範囲はさらに広くなっています。 非同期コンピューティングの問題を考慮してください。

 Thread thread1 = new Thread(() -> { String string = "Hello" + " world"; }); Thread thread2 = new Thread(() -> { int count = "Hello world".length(); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

計算を実行する2つの独立したスレッドがあり、thread1の計算結果に対してthread2の計算を実行する必要があります。 ここでは、この設計を機能させるスレッド同期コードを提供しようとはしません。多くのコードがあり、最も重要なことは、そのような計算ブロックが多数あるとうまく構成されないことです。 しかし、次の2つの単純なアクションを次々に実行したかっただけですが、実行の非同期により、すべてのカードが混乱します。



Java 5でも過度の複雑さを克服するために、Futureが登場し、マルチスレッド計算のブロックをチェーンで整理できるようになりました。 残念ながら、 java.util.concurrent.Futureクラスでは、馴染みのあるmapおよびflatMapメソッドは見つかりません-モナドパターンを実装していません（ CompletableFutureの実装はこれに十分に近いですが）。 したがって、ここでも少しチートをしてJavaを超えて、読者にJava 8で登場した場合にFutureインターフェースがどのようになるか想像する試みを残します。 Scala標準ライブラリのscala.concurrent.Futureトレイトインターフェースを検討してください（メソッドシグネチャは多少簡略化されています）。

 trait Future[+T] extends Awaitable[T] { def map[S](f: T => S): Future[S] def flatMap[S](f: T => Future[S]): Future[S] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

よく見ると、メソッドは非常によく知られています。 mapメソッドは、渡された関数を将来の実行結果に適用します-この結果が利用可能になるとき。 さて、flatMapメソッドは、それ自体が未来を返す関数を使用します。したがって、これら2つの先物はflatMapを使用して連鎖できます。

 val f1 = Future { "Hello" + " world" } val f2 = { s: String => Future { s.length() } } Await.ready( f1.flatMap(f2) .map(println), 5.seconds )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それでは、計算の非同期相互依存ブロックを実行する問題をどのように解決しましたか？

1. 問題は、オブジェクトタイプ（将来[String]）で明確に示されました。
2. 彼らは、このタイプ内に補助コード全体（前のチェーンの最後で次のチェーンを呼び出す）を隠しました。
3. このタイプのオブジェクトに一連の単純なマッチングアクションを渡しました（futur f2はこのタイプのオブジェクト（String）を受け取り、futur f1を返します）。

Future of Scalaもモナドパターンを実装していると要約できます。

まとめ

モナドは、安全でない補助コードのトンによって分離される可能性のあるアクションを簡単に構成（チェーン）できるようにする機能的なプログラミングパターンです。 上記の例に加えて、関数型言語では、モナドを使用して例外的な状況を処理し、I / O、データベース、ステータスなどを処理します。 モナドパターンは、関数が最初のクラスのオブジェクトである任意の言語で実装し（値と見なしたり、引数として渡すなど）、Javaでも一部の場所で遭遇しますが、一部の場所では実装が望まれています最高。



このトピックをより深く理解するには、次のリソースをお勧めします。

• Scala Monads：モナドデザインでコードを整理する
• ブライアン・ベックマン：モナドを恐れない
• マリオ・フスコ モナドジャバ