Nullの扱いについて

開発言語を触っていると、null チェックをうざく感じることがある人は多いだろうなと思う
null objectの存在を見ても、普通のことだと思うが、ラップするってのはC++/stlのauto_ptrやjavaのOptional等を見ても、正直かっちょ悪いと思う
そんな中で、kotlinのように言語レベルでnullを排除しようとしているのは、とてもうれしく思う

なので、どうすれば、null に出会わないコードを書けるかを検討してみたいので、とりあえず気になることを書きなぐってみる

なぜnullが嫌なのか？

nullの一番嫌がられるところは、
if (null ===
という文脈が、ビジネスロジックと関係ない文脈として記載されるところだと思う
よって、いろいろな方がどこまで綺麗にビジネスロジックのみにまとめられるかを考えている

一般的な null 回避の方法としてのラップするケース

まずは、一般的な null 回避の方法を気になる範囲で集めてみる

Collectionを戻り値

if文のようにnullチェックを行う必要は無いので、ビジネスロジックでの違和感が無くなる
List/Array/Map
SQL等で、結果を取得するときにデータが存在しないときは、null が返ってくる時がある
それを、ListやArray等を戻り値とすることで、nullチェックが無くなるというか、アイテムの数チェックを行うことが出来る

Optionalやstd::auto_ptr

nullチェックの代わりに、代替え処理を入れるが1ステートメントで代理値を入れることも可能なのでビジネスロジック上の違和感も薄れる
std::auto_ptr
C/C++ の時は、operator演算子がつかえるので用途次第で違和感なく使えるが、

 int* pint = ptr.get();
```等は、所有権の問題等があり実装方法を気にする必要があります

[Optional](https://docs.oracle.com/javase/jp/8/docs/api/java/util/Optional.html)
利用したいのはオブジェクトにも関わらず、ラップしている為にメソッドを呼び出すことに違和感があります
常に、戻り値のみとして利用するという話も聞いたことはありますが、戻り値として受け取って新たに代入というのもダサいかなと思います

## ***ReactiveのMono/Flux***
***if文のようにnullチェックを行う必要は無いので、ビジネスロジックでの違和感が無くなるかもしれない***
### [mono](http://projectreactor.io/docs/core/release/reference/#mono)
「最大で1つのアイテムを発行し」とあるが、意図して 0 .. 1 のみでラップしている
### [flux](http://projectreactor.io/docs/core/release/reference/#flux)
「0からN個のアイテムを」とあり、意図して 0 .. Nを表している

# **NullObject等のようにnull条件を記載しないケース**
## ***exceptionとtry/catchの存在***
最近は、exceptionとtry/catchを利用することで、ヌルポに起因するsegmentation fault等が発生しなくなっているので、null objectは気にしないでも良いともいえるかもしれない

## ***exceptionが無い場合***
null チェックが行われないときには、メモリーリークが頻発することになり意図しない動きをすることがある
よって、null チェック後に適切なエラーハンドリングを行う必要がある

## ***null object***
objectを戻す際に、object以外の型(null)を返すことで意図しない分岐が生まれることになるが、単一objectが返る場合は、スムーズにロジックを進めることが出来る
但し、すべてのメソッドでそれなりの振る舞い又は、exceptionを返す必要があるので try/catchが前提の昨今では、普通にNullPointerExceptionを投げさせる方が素直かもしれないと思うときもある。