null
を安全に扱うために使用するOptional
の使い方について、自分なりの指針を整理しておこうかなっと。
戻り値にのみ使用する
以上、おわり。
いや、、それだけではだめですよね。。
使用側に通知するため
使用側にとって戻り値がnull
可能性の有無が分かれば防御的実装の有無について判断がやりやすくなるでしょう。結果としてNPE
の発生リスクを軽減させることができるようになります。
多分、これがOptional
の基本指針だと思っています。
引数に使うのはダメなの?
使わない設計思想が良さそうに考えています。
nullかもしれないのだったらオーバーロードを使おう
引数がnull
かもしれないというのであれば、明確に使用しないケースのメソッドを定義する方が使用側にとって分かりやすいメソッドになると思います。
Optional
を引数にしてしまうと、引数指定が汎用的な巨大なメソッドを作りやすくなってしまう。結果として、巨大でなんでもできるメソッドを1つになってしまって、使用側にとって分かりにくい状態になりそう。
でも型だよね?
型なんだから引数にOptional
を使ってもいいじゃないか、というところについての考察。
具体的には、戻り値をそのまま次のメソッドの引数に指定したいケースがあるよね、というところについての考察でもあります。
確かに、そういうことはやりたいのですが、でもそれはロジックが外に漏れだしつつある傾向なのかも。
「受け取ったものを何も操作せずに他に渡すだけ」となっているのでは?
「至る処で対象の戻り値に対して ifPresent
、isPresent
があって、しかもその分岐内の実装が類似」となっているのでは?
こういうケースの場合は、そもそもクラスにまとめた方が良いのかもしれません。
また、null
については 例外と同じように、それを検知した時点で 塗りつぶさず対応をすることを繰り返しておけば 不意のNPE
に悩まされるリスクは減るのではないかなと思っています。
参考
【Java】Optionalの正しい使い方を学ぶ #Java - Qiita
ちゃんと読んでいるわけではありません。
とりあえず、指針に則って実装してみて、なんかやりにくいなと思ったら指針の見直しのための読むためのリンクです。
2024.2.12 追記
https://blogs.oracle.com/otnjp/post/recipes-for-using-the-optional-class-as-its-meant-to-be-used-ja
さいごに
「お前はできてんのか?」
いえ出来ていないですよ(笑)
この指針に則って今後リファクタリングをしよう、という希望を込めた意思表明みたいなものです。