JavaにおけるOptionalによるnull安全のための覚書

Java8から導入されたOptionalを利用することで、よりnull安全なコードを書くことができる。ただし、使い方を間違えるとかえってバグを生むことにも繋がる。適切に利用するための覚書を書く。

nullを返す可能性のあるメソッドは、Optional型を返すメソッドに変更する

これがベースになる。Optionalが導入されるまでは、nullを返す可能性のあるメソッドと返す可能性のないメソッドは言語の上では区別できなかった。そのため、nullを返すかもしれないメソッドを呼び出す際には、プログラマがそれを意識した上で、呼び出し元の方でnullチェックを書く必要があった*1。

Optionalを返すように変更することで何が起きるか。Optional型のオブジェクトが戻り値となることによって、そのまま（Optionalから中身を取り出さずに）利用することが禁止されるのだ。中身を利用するためには、Optional型に定義された各種のメソッドを利用する必要がある。同時に、空のOptional（メソッド変更前のnullに対応）が返ってくることを考慮して呼び出すことも強制されるので、「うっかり」nullが画面に表示されてしまったり、NullPointerExceptionをスローしてしまったりということはなくなる。

nullになる可能性のあるフィールドに対するgetterは、Optional型を返すメソッドとする

これは上の原則に含まれているが、意識しにくいものだと思う。通常、getterというと、以下のようなものを想像する。

public class User {
  private String name;
  public String getName(){
    return this.name;
  }
}

このような（しばしばsetterを一緒に書かれる）getterは、Java プログラマにとっては見慣れたもの（好き嫌いはともかく）だろう。フレームワークがこの種のメソッドの定義を要求している場合もあり、全部を否定するわけではないのだが、Optionalを使ってnull安全なコードを書くという観点からは、この種のgetterは再考に値する。

getterもまた、ひとつのメソッドだ。nullを返す可能性があるのであれば、戻り値の型はOptional型にするべきだ。もしUserのname属性が未設定を許すのであれば、以下のように修正する*2。

public class User {
  private String name;
  public Optional<String> getName(){
    return Optional.ofNullable(this.name);
  }
}

ちなみに、上のようなメソッドを用意する場合、同一クラス内からもフィールドに直接アクセスするのではなく上記のメソッドを利用するようにすべきだ。そうすることで、nullチェックを実装し忘れることを防ぐことができる。このように、外部に対するカプセル化のためのメソッドを自分自身もまた利用することを、自己カプセル化という。Optional型を戻すgetter以外についても使えるテクニックだ。

引数やフィールドにはOptional型を使わない

以上では、メソッドの（nullになる可能性のある）戻り値をOptional型に変更すべきだと書いてきたが、メソッドの（未設定を許容する）引数やフィールドに対しては、Optional型は使わない。

それは、Optional型の引数やフィールドが実行時にnullである可能性を排除できないためだ。下記のようなコードを書いても、思った通りにメソッドが使ってもらえる保証はない。メソッドの利用者は、空のOptionalを渡す代わりに、Optional型のnullを渡すことができてしまう。

public int calculatePrice(Optional<DiscountRate> discountRate){
 // 省略
}

設定を任意としたい引数がある場合には、従来通りnullチェックをメソッド内部で行い、処理を分岐させればいい。一方、nullを許容しない引数については、Javadocコメントにその旨を明記し、実行時にnullが渡された場合に備え、Objects.requireNonNull()等を用いて「防御的プログラミング」を行う。nullを渡さないでくれと言っているメソッドにnullを渡したのであれば、それは利用者側のミスであり、供給者の責任ではない。容赦無くNullPointerExceptionなどをスローして落としてしまえばいい。