Optional,Streamについて。どちらが正しいのでしょうか。

Question

Java8で追加されたOptionalとStreamについていくつか実装について迷った点を質問させていただきます。

###Optional.ofの使い所
以下のようなnullを許容しないフィールドxxxを受け取る関数を実装しようと考えます。Optional.ofはnullを許容しないものでありますが、そうであれば、そのOptionalインスタンスについてorElse等を使える状況を作り出す必要はないと思います。Optional.ofを使ってOptionalを受け取る利点はあるのでしょうか。

final T xxx;

T getXxx() {
  return Objects.requireNonNull(xxx);
}


Optional<T> getXxxAsOptional() {
 return Optional.of(xxx);
}

###Collectionの駆逐
Java8になって、for文からforEachへの移行が行われました。その際、Collectionではstream()を利用してStreamへの変換を行うわけですが、毎回そうする必要はあるのかと疑問に思いました。そこで、Streamをフィールドとして持たせようと考えました。これについて正しいのかどうか教えていただきたいです。
以下について、再代入せずに済む方法もあれば教えていただきたいです。

List<T> list = new ArrayList();
Stream<T> stream = Stream.empty();

void addToList(T t) {
  list.add(t);
}

void addToStream(T t) {
  stream = Stream.concat(stream, Stream.of(t));
}

###Streamが空であるかどうかの判定
Streamが空であるかどうかを以下のように実装するのは正しいのでしょうか(1はcount()が不定なため良くないのかとは思いますが)。正しい方法を教えてください。

Stream stream;

boolean isEmpty1() {
  return stream.count() <= 0;
}

boolean isEmpty2() {
  return stream.findAny().isPresent();
}

Answer 1

nullでないことが保証されているものにOptionalは確かに向きませんね。使い方としては、メソッドの引数などでOptionalを要求するところに渡す際、対象の値がnullでないことを確認することでしょうか…。

Streamは1回使い切りです。一度終端操作を始めたStreamをもう一度使うことはできません。

Streamはデータ集合に対する操作を提供するものなので、「空かどうか」をチェックするのはStreamっぽくないともいえます。

Comments

[ponkotate]

ご回答ありがとうございます。

やはり、Optional.ofはあまり用いることがないのですね。

Streamについてはこちらの勉強不足でした。認識を改めるようにします。ありがとうございました。

Answer 2

Optional.ofの使い所

Optional.ofメソッドは「非nullが保証されるT型の変数」からOptional<T>への変換を行います。質問中のgetXxxAsOptional()メソッド実装はその目的通りですから、特に問題無いと思います。

---

Collectionの駆逐

Streamオブジェクトをクラスフィールドとして持つのは不適切です。Streamオブジェクトは「使い切り」、つまり利用のたびにstream()メソッドにて生成する必要があります。

Java 8 インタフェースStream<T>より引用：

(中間または終端ストリーム操作を呼び出して)ストリームを操作するのは、一度だけにすべきです。このため、たとえば同じソースが2つ以上のパイプラインに対してデータを供給する「フォークされた」ストリームや、同じストリームを複数回トラバースすることなどは、禁止されます。ストリーム実装は、ストリームが再利用されているのを検出すると、IllegalStateExceptionをスローします。ただし、一部のストリーム操作からは新しいストリーム・オブジェクトではなくレシーバが返されることがあるため、場合によっては再利用を検出できない可能性があります。

---

Streamが空であるかどうかの判定

いずれも正しい実装です。要素数が多いときは、短絡評価(short-circuit)を行う後者isEmpty2()メソッドの方が効率が良いと思います。

追記：対象ストリームが無限ストリーム（例：java.util.Random#ints()）の場合、前者isEmpty()メソッドは正常に機能しなくなります。安全性と効率の両面から後者実装の方が好ましいと思いました。

Comments

[yohhoy]

回答中では「Optional.ofを使ってOptionalを受け取る利点」の部分が意図不明のため無視しました。

[ponkotate]

Optionalについて、言葉足らずで申し訳ありません。Optional.ofで生成されたOptionalインスタンスを返すメソッド(ここでいうgetXxxAsOptional)を利用される際、当然中身は空でないことがわかっているため、
getXxxAsOptional().get()
で中身を取り出す等の動作を期待するわけですが、利用する側に立つとブラックボックスとして扱うことになるため、orElse等で本来実行されることのない処理を記述されるかもしれません。そのような危険性のあるOptional.ofに使い所はあるのかという質問でした。

CollectionとStreamに関しては、試行もしくは正確に情報を得ていれば理解できたはずな愚問で申し訳ありません。

空の判定は安心しました。もし使う必要が出た場合は後者を利用するようにします。

[yohhoy]

> 利用する側に立つとブラックボックスとして扱うことになるため、orElse等で本来実行されることのない処理を記述されるかもしれません。そのような危険性のあるOptional.ofに使い所はあるのかという質問でした。

どちらかと言えば、クラス外部設計の観点で考えるべきでしょう。あるメソッドがOptional<T>を返すとき、クラス利用者からは「何らかの有効値または無効値のいずれかが返ってくるメソッド」と認識します。Java 8のOptional<T>型は、まさにこのような使い方のために導入されたクラスです。
→ 参考：http://stackoverflow.com/a/23464794/684921 Stuart Marks氏による回答（同氏はJava仕様策定をリードしている人）

クラス提供者が「Optional<T>を返すが常に有効値だからorElseされると無駄だ」と考えること自体が間違っています。そのような無用な心配をするのではなく、クラス提供者の責任でメソッドの戻り値を単にT型を返すべきです（もちろんnullを返したらどうなるという古典的な問題は残りますが）。言い換えると、メソッドの戻り値型はクラスの“設計意図”を表しているべきです。

[swordone]

orElseを「危険」と捉えていることに違和感を覚えますが…。
ヌルポが発生するのはプログラムが強制終了してしまうため危険ですが、意味のないorElseはただ無駄なだけで危険ではありません。