2014年03月21日

ラムダ禁止じゃなくてラムダ促進を目指してStream APIを考える

今日のJJUGイベントで、Stream APIについて、
@cero_tさんから『ラムダ禁止』でぐぐってみてという話があったのでぐぐった。

ラムダ禁止について本気出して考えてみた - 9つのパターンで見るStream API
これだよね。

Twitterだと書き切れなさそうなので、ブログで書くよ。
あんまり推敲してないから読みにくかったり、おかしい事書いてたら、
生暖かく見守るか、優しく指摘してね。

まず、記事を、1分くらい上から下まで眺めてみたよ。
たぶん、どんどん最新コードを書いていく人にとっては良い記事なんだと思う。

でも、なんて言うか、それ、書く側からの視点に集中しすぎてるんじゃない?と思った。
いやいや、それ以前に、ここに書かれているのって何の例なんだろう。
まぁ、ほとんど読んでいないんだけど(マテ

基本的に、Stream APIは必要があって出来たと思っているんだよね。
だから、Stream APIの使い方が悪くてバグるんだったら、禁止で良いと思う。

もちろん、わたしも禁止なんかしない方が良いと思っているよ。

ただ、記事の下の方に書いてある一覧もラムダ禁止の一種な気がしたりしなかったり。
これだと、使いはじめにくいんじゃないかなぁ。
書いちゃダメというか、書き方はそうじゃない。ってことだと思うの。

理想を言うなら、
  1. どういう理由でStream APIが出来たのか。
  2. なにを実現するためにStream APIが出来たのか。
  3. どういう風にStream APIを適用していくべきなのか。

これを整理しておくことが、利用の促進につなって、ラムダ禁止の抑止になると思う。
整理をしないで、変な書き方スルならその現場はラムダ禁止で良いよ。

たとえば、『Stream API使うとforよりも短いコード行でかけるんだよ!だから使うべきだ!』とか、
『for文は全部Stream APIで置き換えるべきだ!』って言う人はラムダ禁止で良いんじゃないかな!
……そう言うためのAPIじゃない、よ……ね……?( ̄▽ ̄;)

そして、アプリケーションを書くときには、技術要素だけじゃなくて、業務要素を気にしないといけないはず。
業務要素をすっ飛ばして、技術要素に凝った書き方をすると、ラムダ禁止への近道になると思う。

だから、
  1. 技術要素の存在意義を考える。
  2. 業務要素との親和性を考える。
この二つを大事にして、Stream APIとλ式の利用を守っていきたいな。

最終的に、最初にあげた記事みたいにパターンとアンチパターンで埋め尽くされるとしても、
それを掲げるには、もうちょっといろいろ調べていきたいかな。

あ、書き忘れてたけど、
促進をしない現場はいつか禁止になるんじゃないかな。
別に全員が促進する必要は無いと思うけどね。

わたしの現場はわたしが促進するよ。
みんなもガンバレ。

posted by そら at 21:13| Comment(0) | TrackBack(0) | 日記