システム開発で思うところ

JavaEEを主にシステム開発をしながら思うところをツラツラを綴る

Optionalへの考察

nullを安全に扱うために使用するOptionalの使い方について、自分なりの指針を整理しておこうかなっと。

戻り値にのみ使用する

以上、おわり。

いや、、それだけではだめですよね。。

使用側に通知するため

使用側にとって戻り値がnull可能性の有無が分かれば防御的実装の有無について判断がやりやすくなるでしょう。結果としてNPEの発生リスクを軽減させることができるようになります。

多分、これがOptionalの基本指針だと思っています。

引数に使うのはダメなの?

使わない設計思想が良さそうに考えています。

nullかもしれないのだったらオーバーロードを使おう

引数がnullかもしれないというのであれば、明確に使用しないケースのメソッドを定義する方が使用側にとって分かりやすいメソッドになると思います。

Optionalを引数にしてしまうと、引数指定が汎用的な巨大なメソッドを作りやすくなってしまう。結果として、巨大でなんでもできるメソッドを1つになってしまって、使用側にとって分かりにくい状態になりそう。

でも型だよね?

型なんだから引数にOptionalを使ってもいいじゃないか、というところについての考察。

具体的には、戻り値をそのまま次のメソッドの引数に指定したいケースがあるよね、というところについての考察でもあります。

確かに、そういうことはやりたいのですが、でもそれはロジックが外に漏れだしつつある傾向なのかも。

「受け取ったものを何も操作せずに他に渡すだけ」となっているのでは?

「至る処で対象の戻り値に対して ifPresentisPresentがあって、しかもその分岐内の実装が類似」となっているのでは?

こういうケースの場合は、そもそもクラスにまとめた方が良いのかもしれません。

また、nullについては 例外と同じように、それを検知した時点で 塗りつぶさず対応をすることを繰り返しておけば 不意のNPEに悩まされるリスクは減るのではないかなと思っています。

参考

【Java】Optionalの正しい使い方を学ぶ - Qiita

ちゃんと読んでいるわけではありません。

とりあえず、指針に則って実装してみて、なんかやりにくいなと思ったら指針の見直しのための読むためのリンクです。

さいごに

「お前はできてんのか?」

いえ出来ていないですよ(笑)

この指針に則って今後リファクタリングをしよう、という希望を込めた意思表明みたいなものです。