WEB+DB PRESS の Vol.81 から JVM を中心とした連載を始めましたので是非買って下さい。
2014/6/24 発売です。書店には既に並んでいるかと思います。
これはアマゾンのアフィリエイトリンクですので、踏んだ直後に冷蔵庫等の大型家電を購入して頂けると僕が喜びます。
電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。
初回の内容はラムダ式 + RxJava#
今回の内容としては Java8 のラムダ式に関する簡単な説明から、ラムダ式を利用してRxJavaを使うとこんなに便利という話を書きました。
記事内で Stream API に関して説明しなかった最大の理由はラムダ式と Stream API に関する適切で妥当な説明については桜庭さんの記事を読めば良いと考えているからです。
正直に申し上げて、僕も桜庭さんの記事待ちをしています。
次点の理由としては、僕が現在の Stream API を難解な割に既存の API との親和性が低すぎて使えないと考えているからです。
まず、難解な部分としては collect メソッドを第一に挙げておきます。
僕の能力が足りない可能性については否定しませんけども、API ドキュメントを読んでもどう使えば良いかサッパリ分かりません。
Java における既存の API はチェック例外をどんどん送出しますけども、Stream API はチェック例外のある処理を非常に書き辛いのです。java.util.function.BiFunction#apply等を見れば分かりますが、Stream API には例外オブジェクトを使ったエラー処理という概念が、そもそも存在しないのです。
それに対してRxJavaを使うとキチンとしたエラー処理が記述できますので、既存資産との親和性がキープされます。
Akka、Reactor、RxJavaが集まってReactive Streamsという新しい JSR を作る試みが始まっています。
この API がそれなりに妥当な形で定義されれば、現状の残念な Stream API が大きく改善されますので、それを先取りする意味でもRxJavaを学んでおく価値があると僕は考えています。
記事を書きながら悩んだこと#
非常に細かい点なのですけども、今回の記事を書いていて FRP(Functional Reactive Programming)をスタイルと書くかパラダイムと書くか非常に悩みました。
少なくとも既に解決できている問題の大部分を代替できるわけではない
- 「FRP が向いている領域」と FRP が向いてない領域」がある
既存のやり方に比べて大幅に生産性や品質が向上するわけではない
- Java でオブジェクトが状態を維持しないモデルのコードを書くのは明らかに難しい
ことから、僕は FRP をある種のプログラミングスタイルであってプログラミングパラダイムと呼べるほど大げさな違いでは無いと結論付けましたので、記事内では FRP をスタイルであると説明しました。
異論や反論はあってしかるべきだと考えていますので、twitter なりブログなりで意見を聞かせていただけると嬉しいです。
最後に#
記事内で説明していないコードがサンプルコードには含まれていますので、是非お試し下さい。