Null安全のその先へ：DIコンテナにおける「初期化待ち」の静的解決と型安全の極致
DartのSound Null Safetyは、単なる「Nullを防ぐためのガードレール」ではない。それは、コンパイル時にプログラムの「状態の遷移」を証明するための強力な論理システムだ。
多くのエンジニアがProviderやRiverpodを用いる際、DIコンテナ内での「初期化前のNull許容（Nullable）問題」に直面し、安易に `late` や `!`（強制アンラップ）を多用して自ら型安全性を破壊している。これは、Dart VMが最適化のために静的型情報を利用する恩恵を自ら捨てていることに等しい。
本稿では、DIコンテナにおけるNull安全の「あるべき姿」を、アーキテクトの視点から紐解く。
—
1. アンチパターンの解剖：なぜ `late` や `!` が毒になるのか
まず、現場で散見される「危険なコード」を見てほしい。
// 典型的なアンチパターン
class AuthService {
User? _user;
User get user => _user!; // 強制アンラップ！
void login(User user) => _user = user;
}
この実装の何が問題か。`user` にアクセスするコンシューマーは、`AuthService` が「いつ初期化されたか」という時系列の依存関係をコンパイル時に一切知ることができない。`! ` を使うことは「このコードは将来的にランタイムエラーでクラッシュする権利を放棄します」と宣言しているに等しい。
Dartのコンパイラは、`!` がある箇所では「ここがNullならクラッシュして当然」というコードを生成する。私たちは、「Nullである可能性」をコンパイル時に排除するアーキテクチャを組まなければならない。
—
2. 結論：状態を「型」で表現せよ
DIコンテナにおける初期化問題は、Null許容型（`T?`）で解決するのではなく、「状態の型（State pattern）」で解決すべきだ。
Riverpodの `AsyncValue` や、独自のドメインモデルを用いることで、コンシューマー側に「今、そのデータは存在するか？」を型として強制的に意識させる。
実践的な設計：依存性注入の型安全パターン
/// 認証状態を明示的な型で定義する
sealed class AuthState {
const AuthState();
}
class AuthUninitialized extends AuthState {}
class AuthAuthenticated extends AuthState {
final User user;
const AuthAuthenticated(this.user);
}
/// DIコンテナ内では「Null」を管理せず「状態」を管理する
class AuthController extends StateNotifier
AuthController() : super(AuthUninitialized());
void login(User user) => state = AuthAuthenticated(user);
}
この設計の利点は、コンシューマー側で `switch` 文による網羅的なチェックを強制できる点にある。
// コンシューマー側（UI層）
final authState = ref.watch(authProvider);
return switch (authState) {
AuthUninitialized() => CircularProgressIndicator(),
AuthAuthenticated(:final user) => Text(‘Welcome, ${user.name}’),
};
このように記述すれば、`user` が `null` になる可能性をコンパイル時に完全にゼロにできる。これがDartのSound Null Safetyを活かしきるということだ。
—
3. パフォーマンスとコンパイラの挙動：Isolateと型チェック
Dart VMは、型情報が明確であればあるほど、内部で最適化を働かせる。特にAOTコンパイル時、`!` によるランタイムチェックよりも、`switch` によるパターンマッチングの方が、型推論エンジンにとっては遥かに「読みやすい」コードとなる。
また、非同期API連携を行う場合、`Future` を単に返すのではなく、`AsyncValue` を用いた状態管理を行うべきだ。 `Future.then` で値を代入するようなレガシーな手法は、Isolateの境界を跨ぐ際のデータの一貫性を損なうリスクがある。
—
4. プロダクションコードにおける「美学」
私がコードレビューで必ず指摘するのは、「インターフェースが Null を語っていないか」という点だ。
もしDIコンテナから取得する値が、ビジネスロジック的に「存在しないこと」を許容するなら `Option` パターン（fpdartなどのライブラリを活用）を検討すべきだ。しかし、UI層の初期化待ちであれば、上記の `sealed class` による状態遷移が最も堅牢である。
プロダクション実装のチェックリスト
1. `late` を禁止せよ: 初期化が不確実なら、それは `late` ではなく `AsyncValue` や `State` オブジェクトであるべきだ。
2. `!` を追放せよ: コードの中に `!` があれば、それは「設計の敗北」と見なせ。
3. コンシューマーの責務を限定せよ: コンシューマーは「Nullチェック」をするのではなく、「状態をパターンマッチング」するだけで済むようにインターフェースを設計する。
最後に：言語を掌握するということ
Dartは、Googleが大規模なUI開発のために磨き上げた言語だ。この言語は、あなたがNullを恐れることを望んでいない。Nullを「状態」として型システムの中に閉じ込め、コンパイル時にその状態を解決することを求めている。
「動けばいい」というコードは、数ヶ月後の自分に技術的負債という名の爆弾を渡しているに過ぎない。型を制する者が、Dartのパフォーマンスと保守性を完全に支配する。
次のプルリクエストからは、`!` を削除することから始めてほしい。それが、世界最高峰のアーキテクトへの第一歩だ。