Java から Kotlin へ

第4章. オプショナルからNullableへ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

トニー・ホーアは、ヌル・レファレンスの発明を10億ドルの過ちだと考えているかもしれない、¹しかし、私たちのソフトウェア・システムには、モノが存在しないことを表現する必要がある。Kotlinを使ってnullを受け入れつつ、安全なソフトウェアを作るにはどうすればいいのだろうか？

欠席を表す

JavaプログラマにとってKotlinの最も魅力的な特徴は、型システムにおけるnullabilityの表現だろう。 これもJavaとKotlinの粒が異なる部分だ。

Java 8 より前の Java では、null にできる参照とできない参照を区別するために、慣習、文書、直感に頼っていた。 コレクションから項目を返すメソッドは、null を返すことができなければならないと推論できるが、addressLine3 はnull にできるのか、それとも情報がないときは空の文字列を使うのか。

addressLine3OrNull previousAddressOrNull何年もかけて、著者とその同僚たちは、Javaの参照はフラグが立っていない限りnullでないと仮定する慣例に落ち着いた。 コードベース内では、これは十分に機能する（少々冗長で、NullPointerExceptionの災いを避けるために永遠の警戒が必要だとしても）。

一部のコードベースは、代わりに@Nullable 、@NotNullable アノテーションを使うことを選択し、多くの場合、正しさをチェックするツールによってサポートされていた。 2014年にリリースされたJava 8では、アノテーションのサポートが強化され、チェッカー・フレームワークのようなツールが、NULLの安全性だけでなく、多くのことを静的にチェックできるようになった。 しかし、より重要なのは、Java 8では標準のOptional 型も導入されたことだ。

この頃までに、多くのJVM開発者がScalaに手を出していた。彼らは、不在が可能な場合はOptional型（Scalaの標準ライブラリではOption という名前）を使い、そうでない場合はプレーン参照を使う利点を理解するようになった。Oracleは、開発者にフィールドやパラメータの値にOptional を使わないように言ってお茶を濁したが、Java 8で導入された多くの機能と同様に、これは十分な利点であり、Javaの主流の使い方に採用された。

年代にもよるが、あなたのJavaコードは、不在を処理するために、これらの戦略の一部または全部を使っているかもしれない。Null⁠Pointer​Excep⁠tionが実質的にまったく見られないコードベースを持つことは確かに可能だが、現実にはこれは大変な仕事だ。Javaはnullによって重くのしかかり、中途半端なOptional 型によって恥ずかしくなる。

対照的に、Kotlinはnullを受け入れている。オプショナリティを標準ライブラリではなく型システムの一部にすることは、Kotlinのコードベースが欠損値の扱いに統一性を持たせることを意味する。 すべてが完璧というわけではない。Map<K, V>.get(key) は、key に値がない場合、null を返す。しかし、List<T>.get(index) は、index に値がない場合、IndexOutOfBoundsException ...