【実務・中級編】Dartの共変性（Covariance）とNull安全：Listが引き起こす実行時エラーの回避術 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dartの型システムを飼いならす：共変性（Covariance）が引き起こす「実行時爆弾」を解体する

DartのSound Null Safetyは、単なる「nullを排除する仕組み」ではない。それは、コンパイル時に型安全性を保証し、実行時のVMにおける型チェックのオーバーヘッドを最小化するための強力な制約だ。

しかし、実務で多くのエンジニアが躓くのが「共変性（Covariance）」と「ジェネリクス」が交差する地点だ。特に、`List`や`List`を扱う際、コンパイラが許容してしまったコードが、実行時に`TypeError`を吐き出しアプリをクラッシュさせる。

なぜ、Dartは一見安全に見えるコードで実行時エラーを起こすのか。今日はその深淵を覗き、プロダクションコードを堅牢にするための「設計の作法」を伝授する。

—

1. なぜ「共変性」が罠になるのか

Dartのジェネリクスはデフォルトで共変（covariant）だ。
例えば、`List`は`List`のサブタイプとして扱われる。これは直感的だが、型システムにとっては危険な橋だ。

List strings = [‘Dart’, ‘Flutter’];
List objects = strings; // 共変性のおかげで代入可能

objects.add(100); // コンパイルは通るが…
// 実行時に strings は [‘Dart’, ‘Flutter’, 100] となり、
// strings[2] にアクセスした瞬間に内部の型不整合でクラッシュする。

これが「Sound Null Safety」の世界であっても変わらない。`List`や`List`を不用意に渡すと、コンパイル時には型安全に見えても、実行時のVM内部で想定外の型が紛れ込み、破壊的な結果をもたらす。

—

2. 実務で遭遇する「Null許容」の落とし穴

APIレスポンスを扱う際によくあるパターンを見てみよう。

// 悪い設計：型を曖昧にして共変性に逃げている
void processItems(List items) {
// コンパイル時は items が何でもありなので、
// 中身が null なのか String なのかを毎回チェックする必要がある。
for (final item in items) {
if (item is String) {
print(item.toUpperCase());
}
}
}

このコードの問題点は「型システムがプログラマの意図を理解できていないこと」だ。`List`を受け取った時点で、我々は型安全性の恩恵を放棄している。

解決策：不変性（Invariance）を強制する

ジェネリクスを定義する際、可能な限り「具象型」に閉じること。もし汎用的な処理が必要なら、`covariant`キーワードや、抽象化レイヤーでの制約を検討せよ。

—

3. プロダクションコード：型安全なデータ変換パターン

API連携において、「Null許容」と「共変性の罠」を回避するための、保守性の高い実装パターンを紹介する。Mapperパターンの活用だ。

/// 外部からの生データを、ドメインモデルへ変換する堅牢なレイヤー
class UserMapper {
// dynamicをListに限定し、即座に型変換を行う
static List fromJsonList(List rawData) {
// フィルタリングと型キャストを分離し、実行時の型エラーを早期検出する
return rawData
.map((e) => e as Map)
.map((json) => User.fromJson(json))
.toList();
}
}

class User {
final String id;
final String? name;

User({required this.id, this.name});

factory User.fromJson(Map json) {
// 型安全を強制するため、asでキャストするのではなく、
// 期待する型でない場合は例外を投げるか、デフォルト値を設定する
return User(
id: json[‘id’] as String,
name: json[‘name’] as String?,
);
}
}

この設計が「美しい」理由

1. 境界での責任分離: 外部から来た危険な`dynamic`を、`UserMapper`という境界で叩き切り、ドメイン内では純粋な`List`として扱う。
2. 早期リターンとガード: `as`によるキャストを境界に集約することで、型不整合が起きた際に「どこで壊れたか」がスタックトレースから一目瞭然になる。
3. VMの最適化: Dart VMは型が確定しているリスト（`List`）に対して、より最適化されたメモリ確保とアクセスを行うことができる。

—

4. チーフアーキテクトからの助言

  • `List`は「特急券」ではない: 開発速度を上げるための`dynamic`の使用は、将来の自分への借金である。コンパイル時の警告を無視して`dynamic`を乱用するな。
  • `covariant`キーワードの使い所: クラス継承時、オーバーライドするメソッドの引数の型をサブクラス側で広げたい場合にのみ使う。それ以外の場面で使うのは、設計の敗北だ。
  • コレクションの不変性: 可能な限り `final` を付け、`List.unmodifiable` 等を使って予期せぬ状態変更をVMレベルで防げ。

Dartの型システムは「性善説」ではない。あなたが型システムを厳格に定義すれば、VMは最高のパフォーマンスで応えてくれる。「実行時エラー」を「コンパイル時エラー」に引きずり下ろすことこそが、エンジニアとしての力量だ。

型システムを飼いならし、美しいコードを書き続けろ。それが、伝説への第一歩だ。

スポンサーリンク
タイトルとURLをコピーしました