Java | Java 詳細・モダン文法：Optional – Optional 設計思想

Java Java
スポンサーリンク

Optional が生まれた一番大きな理由

Optional が Java に入ってきた一番の理由は、「null による事故を減らしたい」これに尽きます。
Java の世界では長いあいだ、「値がないこと」を表す手段として null しかありませんでした。

見つからないユーザーを返すときに null を返す。
オプションの値が設定されていないときに null を返す。

こういうコードが積み重なった結果、どこかで null チェックを忘れた瞬間に NullPointerException が飛ぶ。
しかも「どこで null が入ったのか」が追いにくい。
このパターンに、みんなうんざりしていたわけです。

Optional は、「値がないかもしれない」という事実を、null ではなく「型」で表現するためのクラスです。
「ここは null かもしれないよ」とコメントで書くのではなく、「ここは Optional<T> だよ」と型で宣言する。
これが設計思想の出発点です。

「0 個か 1 個の値を持つ箱」というモデル

Optional<T> を一言で言うなら、「T を 0 個か 1 個だけ入れられる箱」です。
中身がある状態が Optional.of(value)、中身がない状態が Optional.empty()。

ここで大事なのは、「null を入れる箱」ではない、ということです。
Optional.of(null) は例外になりますし、Optional の中に null を入れる設計はそもそも想定されていません。

「値があるかもしれないし、ないかもしれない」という状況を、

T か null か、ではなく
Optional<T> という 1 つの型で表す。

これによって、「このメソッドは値がない可能性がある」という情報が、コンパイル時に見えるようになります。
呼び出し側は、null チェックを「忘れる」ことができなくなる。
ここが設計思想として一番重要なポイントです。

典型例：検索メソッドの戻り値をどう設計するか

例えば、ID からユーザーを探すメソッドを考えてみます。

昔ながらの書き方だと、こうなりがちです。

User findById(int id) {
    // 見つからなければ null を返す
}
Java

呼び出し側は、毎回こう書かないといけません。

User user = findById(10);
if (user != null) {
    System.out.println(user.getName());
}
Java

そして、どこかでこの if (user != null) を書き忘れた瞬間に NullPointerException です。

Optional を使うと、シグネチャをこう変えられます。

Optional<User> findById(int id) {
    // 見つからなければ Optional.empty() を返す
}
Java

呼び出し側は、こう書くことになります。

findById(10)
        .ifPresent(user -> System.out.println(user.getName()));
Java

あるいは、こうです。

String name =
        findById(10)
                .map(User::getName)
                .orElse("ゲスト");
Java

ここで起きていることは、「null チェックを if 文で書く」のではなく、「Optional のメソッドを通して“ないかもしれない”ことを扱う」スタイルに変わっている、ということです。
findById の戻り値が Optional<User> になった瞬間に、「このメソッドは見つからない可能性がある」という情報が型に刻まれます。
これが設計思想としての大きな勝利です。

Optional のメソッド設計に込められている考え方

Optional にはたくさんメソッドがありますが、設計思想として特に重要なのは「null を使わせない」「if だらけにさせない」という二つです。

get() は「中身があると信じて取り出す」メソッドですが、中身がなければ例外になります。
だから本来は、「どうしてもここでなければおかしい」という場面以外では使うべきではない、という位置づけです。

代わりに用意されているのが、orElse や orElseGet、orElseThrow です。

User user =
        findById(10)
                .orElseThrow(() -> new IllegalArgumentException("not found"));
Java

こう書くと、「見つからなければこの例外を投げる」という意図が、if 文よりもはっきり表現できます。

また、map や flatMap は、「中身があるときだけ変換する」ためのメソッドです。

Optional<String> maybeName =
        findById(10)
                .map(User::getName);
Java

中身がなければ何も起きず、そのまま Optional.empty() が返ってきます。
ここでも、「null チェックしてからメソッドを呼ぶ」という命令的な書き方ではなく、「あるときだけ変換する」という宣言的な書き方に寄せていく、という思想が見えます。

「フィールドや引数には使わないで」という設計思想

Optional の公式なドキュメントでは、「フィールドやメソッド引数に Optional を使うべきではない」と明言されています。

これは、「Optional はあくまで“戻り値用のコンテナ”として設計されている」という思想の表れです。

エンティティのフィールドに Optional を持たせ始めると、

Optional<Optional<T>> のような二重構造が生まれたり
シリアライズやフレームワークとの相性が悪くなったり

といった問題が出てきます。

設計としては、

内部の世界（フィールドやローカル変数）では、null を許容するかどうかを自分たちのルールで決める。
外向きの API（メソッドの戻り値）で、「ないかもしれない」を表現したいときにだけ Optional を使う。

この線引きが、Optional の設計思想に沿った使い方です。

「null をなくす」のではなく「null を閉じ込める」

Optional の導入で誤解しがちなのは、「これで null がなくなる」という期待です。
実際には、Java の世界から null が消えることはありません。

データベースから値を読み込むとき
外部ライブラリを呼び出すとき
古いコードと連携するとき

どこかで必ず null と向き合う必要があります。

Optional の設計思想は、「null を世界から消す」ではなく、「null を“外側”に漏らさない」です。

外部から null が来るかもしれないところで、それを受け止めて Optional に包む。
内部では Optional を使って「ないかもしれない」を安全に扱い、最後にまた Optional として返す。

こうすることで、「null が飛び交う範囲」を最小限に閉じ込めることができます。
null を完全にゼロにするのではなく、「null と付き合う場所を限定する」のが、現実的な落としどころです。

Optional 設計で一番大事な問いかけ

最後に、Optional を設計に使うとき、毎回自分に投げてほしい問いを一つだけ挙げます。

「このメソッドの呼び出し側に、“値がないかもしれない”という事実を、ちゃんと伝えたいか？」

伝えたいなら、戻り値を Optional<T> にする。
「ここで値がないのはありえない」「なければバグ」という場面なら、Optional ではなく素直に T を返し、内部で例外にする。

Optional は「なんとなく安全そうだから付ける飾り」ではなく、「呼び出し側との契約を型で表現するための道具」です。
この感覚が腹に落ちると、Optional の設計が一気に気持ちよくなります。

スポンサーリンク
タイトルとURLをコピーしました