導入：Kotlinの「nullable地獄」、ここで詰まる
Kotlinを書き始めて、だいたい最初にこうなります。
「? が多すぎて何が何だかわからない」
「!! を付けたら落ちた」
「結局nullって何？」
これ、ほぼ全員が通る道です。安心してください。
この記事では、Kotlin初心者が最初に覚えるべき nullable（null許容）回避パターンを、
コピペで動く例 → 実務の落とし穴 → 設計視点までまとめます。
先に結論です。
- !! は原則使わない
- nullは「受け取り口」で潰す
- 設計でnullableを減らすのが最強
基礎：nullableとは何か
Kotlinでは、nullが入るかどうかを型で表します。
var name: String = "Taro" // nullは入らない
var nickname: String? = null // nullが入る
ここがJavaとの一番の違いです。
null安全をコンパイル時に守るのがKotlinの思想です。
なぜ「地獄」になるのか
nullableをそのまま伝播させると、
user?.profile?.address?.zipCode
みたいなコードが量産されます。
読めない・直せない・怖い。ここで心が折れます。
まず覚える最小パターン集
① Elvis演算子（?:）
val name = user.name ?: "未設定"
nullだった場合のデフォルト値を決める基本技です。
② letでnullチェック
user?.let {
// userがnullでない時だけ実行
showUser(it)
}
UI更新や副作用のある処理でよく使います。
③ requireNotNull / checkNotNull
val id = requireNotNull(userId) { "userId must not be null" }
「ここでは絶対nullじゃない」という設計上の保証をコードに残せます。
④ safe call + return
val user = repository.getUser() ?: return
早期リターンで、以降の処理をnon-nullにできます。
実務でのnullable地獄パターン
① !! の常用
「動くから」で !! を付け始めると、
クラッシュ製造機になります。
② nullableをDTOからUIまで引きずる
APIレスポンスのnullableをそのままViewまで持ってくると、
画面全体が ? だらけになります。
③ プロパティをvar + nullableで逃げる
「後で入るから null」で設計すると、
初期化タイミングが地獄になります。
④ non-null前提なのに型がnullable
コードと設計の意図がズレているサインです。
安全に書くベストプラクティス
| 場面 | おすすめ |
|---|---|
| APIレスポンス | nullableで受ける |
| UseCase / Repository | nullを変換・補正 |
| UI層 | 原則non-null |
nullableは境界で処理する。
これを意識するだけでコードが激変します。
応用：設計でnullableを消す
初期化必須コンストラクタ
data class User(
val id: String,
val name: String
)
nullableを許さない設計が一番強いです。
UIモデルを別で作る
APIモデルとUIモデルを分けると、
UI側はnon-nullだけで書けます。
sealed classで状態を表現
sealed class UiState {
object Loading : UiState()
data class Success(val user: User) : UiState()
object Error : UiState()
}
nullの代わりに状態で表すのが上級者パターンです。
デバッグ・確認チェックリスト
- !! を使っていないか
- nullableがUIまで漏れていないか
- Elvis演算子で意図が明確か
- 設計上non-nullなものがnullableになっていないか
よくある質問
Q. !! は完全に禁止？
原則NGですが、テストコードなど限定的な場面では許容されることもあります。
Q. nullableが多いAPIはどうする？
Repository層で変換し、UIには渡さないのが基本です。
Q. Kotlinに慣れれば自然に減る？
減ります。ただし設計を意識しないと減りません。
まとめ
- nullは悪ではなく「設計のサイン」
- 境界で処理すれば地獄は来ない
- 最終的には設計で解決する
迷ったら：UI層はnon-nullにする。
コメント