こんにちは。Dartの深淵を覗き込み、その挙動を慈しむ開発者の皆さん。
Dartの「Sound Null Safety」は、単なるエラー回避の手段ではありません。コンパイル時の静的解析を通じて、「実行時にNullPointerException（DartではNoSuchMethodError）を物理的に不可能にする」という、型システムの勝利なのです。
今回は、DI（Dependency Injection）コンテナ、特にProviderやRiverpodといった現代的なDartアプリケーションの心臓部において、このNull安全とどう向き合うべきか、その極意を伝授します。
—
1. Null安全の真実：コンパイラとの約束
DartのNull安全において、最も重要なのは「型システムが変数の生存期間をどう認識しているか」です。
DIコンテナを使っていると、「初期化されるまではNullであり、その後は非Nullである」という状況によく遭遇します。これを安易に `T?` と定義して `!` でこじ開けていませんか？それはコンパイラに対する背信行為です。
陥りやすい罠：安易な `!` 演算子
// 危険なコードの典型
class Service {
late MyRepository? repo; // 初期化前はnullを許容したいが…
void init() => repo = MyRepository();
void execute() {
// コンパイラはrepoがnullかもしれないと疑っている
repo!.doSomething(); // ここで「!」を使うのは敗北です
}
}
なぜこれが敗北なのか。それは、`repo` がNullである可能性をプログラムが制御できておらず、実行時のクラッシュリスクを開発者の責任（`!`）に丸投げしているからです。
—
2. DIにおける「初期化前」をどう設計するか
ProviderやRiverpodでサービスを注入する場合、「Nullである時間」を極限まで短くするか、「最初からあるべき状態」で定義するのが鉄則です。
推奨：lateキーワードとファクトリの活用
Dartの `late` は、単なる「遅延初期化」ではありません。「実行時までには必ず値が代入されていることを保証する」というコンパイラへの誓約書です。
// 安全なDI設計の例
class AppContainer {
// lateを使うことで、コンシューマーはnullチェックから解放される
late final MyService service;
void bootstrap() {
// 依存関係を組み立てる
service = MyService(Repository());
}
}
ここで重要なのは、`late` を使うことで、`Service` を利用する側は `repo?.doSomething()` のような冗長なチェックを書く必要がなくなる点です。「コンテナが初期化を保証するなら、利用者は安全に振る舞える」。これがDIの哲学です。
—
3. Riverpodにおける「状態の遷移」とNull許容型
Riverpodのような状態管理ライブラリでは、`AsyncValue` を使うのがDartの流儀です。DIコンテナのデータ取得が非同期である場合、Null許容型をこねくり回すのではなく、「状態としてのNull（ローディング中・エラー中）」を型で表現しましょう。
// RiverpodのProvider例
final userProvider = FutureProvider
// ここでNullを返すことはせず、非同期処理の結果を待つ
return await fetchUser();
});
// コンシューマー側
ref.watch(userProvider).when(
data: (user) => Text(user.name), // ここでは確実に非Null
loading: () => CircularProgressIndicator(),
error: (err, stack) => Text(‘Error!’),
);
注目してください。ここでは「Nullかどうか」を判定するのではなく、「データが存在する状態（data）」か「そうでない状態（loading/error）」かを型安全に分岐させています。これがDartのNull安全を最大限に活かす設計です。
—
4. 現場で使える「型制御」のテクニック
どうしても「Nullである期間」が発生してしまう場合は、以下のルールを守ってください。
1. `?` を公開インターフェースに持ち込まない: 内部的に `T?` を保持していても、Getterで `T` として返すようにし、その際に「まだ初期化されていない場合は例外を投げる」あるいは「デフォルト値を返す」ロジックをカプセル化しましょう。
2. `late` を信じすぎない: `late` 変数にアクセスする前に値を代入し忘れると、実行時に `LateInitializationError` が発生します。DIコンテナの起動シーケンスは、必ず同期的に完了するように設計してください。
究極のインターフェース設計
class DependencyContainer {
MyService? _service;
// 外部には「確実に存在するもの」として提供する
MyService get service {
final s = _service;
if (s == null) {
throw StateError(‘Container is not initialized!’);
}
return s;
}
}
このように、Getterを通じて「存在しなければエラーを投げる（＝プログラマのミスを即座に検知する）」設計にすることで、利用側では Null チェックを排除でき、コードが劇的にクリーンになります。
—
最後に：Dartを掌握するために
Null安全とは、コードに「制約」を課すものではなく、「コードがどうあるべきか」という設計図を明確にするための言語機能です。
DIコンテナを設計する際、「Null許容型」を安易に使いたくなったら、それは設計を見直すサインかもしれません。「本当にNullである必要があるのか？」「ローディング状態として表現すべきではないか？」と自問自答してみてください。
ここをクリアすれば、あなたの書くDartコードは、実行時エラーとは無縁の、堅牢で美しい芸術品へと昇華されます。さあ、次はどんな複雑な依存関係に挑みますか？応援していますよ。