【実務・中級編】Dartの「final」変数の再代入をコンパイル時に防ぐための設計パターン – Dart コア文法・オブジェクト指向・Null安全解析バイブル

コードレビューをしていて、次のようなコードに出くわしたことはないだろうか。

// よくある「変更される前提」の冗長な状態管理
String userRole = ‘guest’;

void updateRole(String newRole) {
if (newRole == ‘admin’ || newRole == ‘user’ || newRole == ‘guest’) {
userRole = newRole;
} else {
userRole = ‘guest’; // フォールバック
}
}

このコードの何が問題か。「変数が再代入可能（`String`）であること」そのものが、バグの温床であり、設計の敗北だ。フロントエンドのコンポーネント設計や、複雑な非同期API連携のステート管理において、変数がどこかで書き換えられる可能性があるというだけで、認知負荷は跳ね上がり、予期せぬレンダリングバグや競合状態（Race Condition）の餌食になる。

Dart 3の登場によって、我々は言語仕様の根底から「再代入」を排除し、コンパイラの静的解析能力を極限まで引き出したイミュータブルな設計を手に入れた。

本記事では、Dartの `final` と Dart 3のパターンマッチング（Switch Expressions & Patterns）を融合させ、「コンパイル時に不正な状態を完全にコンパイルエラーとして弾く」実戦的な設計パターンを叩き込む。

—

なぜ `final` とパターンマッチングの組み合わせが最強なのか？

Dartのコンパイラ（CFA: Control Flow Analysis）は非常に優秀だ。`final` キーワードと網羅的な（Exhaustive）パターンマッチングを組み合わせることで、Dart VMは「この変数は初期化された後、二度と書き換えられない」かつ「取りうる状態が完全に網羅されている」と断定できる。

これにより、以下のメリットがもたらされる。

1. 偶発的なミューテーションの完全封鎖: ヒューマンエラーによる状態の書き換え余地がコード上から消滅する。
2. 網羅性チェック（Exhaustiveness Checking）による安全性: 新しい状態（EnumやSealedクラスのバリエーション）を追加した際、ハンドリングし忘れるとコンパイルエラーになる。
3. AOTコンパイル時の最適化: 不変性が保証されることで、DartのCFAおよびAOTコンパイラ（特にFlutter Web等で使用されるWasm/JSコンパイラ）は、不要なメモリバリアや防衛的コピーを排除したアグレッシブな最適化を行える。

—

実践：API連携とUI状態を堅牢に保つプロダクションコード

例として、Webフロントエンドや非同期API連携で頻出する「リモートデータの非同期フェッチ状態（未取得、ローディング、成功、エラー）」を設計する。

以下のコードは、`sealed` クラス、`final` 変数、そして Dart 3のパターンマッチングを駆使し、「不正な状態遷移や再代入を構造的に不可能にした」プロダクションコードだ。

import ‘dart:async’;

// 1. 状態を Sealed クラスで厳格に定義
sealed class AsyncUiState {
const AsyncUiState();
}

class AsyncIdle extends AsyncUiState {
const AsyncIdle();
}

class AsyncLoading extends AsyncUiState {
const AsyncLoading();
}

class AsyncData extends AsyncUiState {
const AsyncData(this.data);
final T data; // データ自体もイミュータブル
}

class AsyncError extends AsyncUiState {
const AsyncError(this.error, this.stackTrace);
final Object error;
final StackTrace stackTrace;
}

// 2. ViewModel / Controllerでの状態管理パターン
class UserProfileController {
// 状態変数は常に final。再代入は絶対にさせない。
// 状態を更新する場合は、新しいインスタンスを生成して「置き換える」。
var _state = const AsyncUiState>const AsyncIdle();

// 外部にはイミュータブルな状態のみを公開
AsyncUiState> get state => _state;

/// 非同期API連携と安全な状態遷移
Future fetchUserProfile(String userId) async {
// 状態の遷移をイミュータブルにスワップ
_state = const AsyncLoading();
_notifyListeners();

try {
// ネットワーク遅延のシミュレーション
await Future.delayed(const Duration(milliseconds: 800));

// ダミーのAPIレスポンス
final response = {
‘id’: userId,
‘name’: ‘Dart Architect’,
‘role’: ‘Core Committer’,
};

// 成功状態へイミュータブルに移行
_state = AsyncData(response);
} catch (e, st) {
// エラー状態へイミュータブルに移行
_state = AsyncError(e, st);
} finally {
_notifyListeners();
}
}

void _notifyListeners() {
// UIへの通知処理（Flutterであれば notifyListeners() など）
print(‘State updated: ${_state.runtimeType}’);
}
}

// 3. UI層・コンポーネント設計におけるパターンマッチングの活用
String renderUiComponent(AsyncUiState> state) {
// Dart 3の Switch Expression による「網羅的」なパターンマッチング
// ここで網羅漏れがあると、コンパイルエラーになる。
return switch (state) {
AsyncIdle() => ‘Press button to load profile.’,
AsyncLoading() => ‘Loading profile, please wait…’,
AsyncData(:final data) => ‘Welcome, ${data[‘name’]} (${data[‘role’]})!’,
AsyncError(:final error) => ‘Failed to load profile: $error’,
};
}

void main() async {
final controller = UserProfileController();

print(renderUiComponent(controller.state));

// 非同期処理の実行
await controller.fetchUserProfile(‘user_001’);

print(renderUiComponent(controller.state));
}

—

コードレビューの視点：なぜこの設計が優れているのか？

上記のコードにおいて、テックリードとして以下の設計思想を推す理由を解説する。

A. 変数の `final` 化ではなく「状態の置き換え（State Replacement）」

変数を `final` にするということは、「値を書き換えない」ことと同義ではない。上記コードの `_state` は `var` だが、これは「コンテナとしての参照を新しいイミュータブルな状態オブジェクトで置き換えている」に過ぎない。
状態そのものが `const` コンストラクタで生成されるイミュータブルなオブジェクトであるため、どこかの処理が勝手に `state[‘role’] = ‘hacker’` のような破壊的変更（Mutation）を行うことが型レベルで不可能になっている。

B. Switch 式（Switch Expressions）によるデフェンシブ・プログラミング

従来の `if-else` や網羅性のない `switch-case` は、新しい状態クラス（例: `AsyncMaintenance` など）を追加した際に、UI側のハンドリング漏れを見逃しやすい。
しかし、Dart 3の Switch 式はコンパイラがすべてのサブタイプが処理されているかを強制的に検証するため、「新しい状態を追加したのにUIの表示落ち（バグ）が発生する」というインシデントをコンパイル時に100%防止できる。

—

パフォーマンス上の注意点：イミュータブルとオブジェクト生成コスト

「毎回新しい状態オブジェクトを生成すると、GC（ガベージコレクション）の負荷が高まるのではないか？」という懸念を持つ優秀なエンジニアもいるだろう。

結論から言えば、Dart VMのジェネレーショナルGCは、短命なオブジェクト（Ephemeral objects）の回収において極めて高速に動作する。さらに、`const` コンストラクタを積極的に活用することで、コンパイル時にインスタンスがメモリー上にキャッシュされるため、`AsyncIdle()` や `AsyncLoading()` のようなパラメータを持たない状態はインスタンスすら再生成されない。

ただし、巨大なリストやマップを毎回の状態更新でコピーするのは避けるべきだ。イミュータブルなデータ構造を扱う際は、パッケージ（例: `fast_immutable_collections` や `freezed`）の活用、あるいはオブジェクトの浅いコピー（Shallow Copy）に留めるなど、メモリフットプリントへの配慮は常に忘れないこと。

—

まとめ：明日からのコードレビューで意識すべきこと

リファクタリングの際、次のチェックリストをチームに浸透させてほしい。

1. 「再代入可能な変数（`var` や `String`, `int` のプロパティ）」を見つけたら、即座に `final` またはイミュータブルなオブジェクトへの置き換えを検討したか？
2. 状態分岐に `if-else` や不完全な `switch` を使っていないか？（Dart 3の Switch Expression と Sealed クラスによる網羅性チェックを使っているか？）
3. 外部から書き換えられるべきでないデータが、ミュータブルなコレクションのまま露出していないか？

言語の仕様を深く理解し、コンパイラを味方につけること。それこそが、バグの温床を断ち切り、スケールするプロダクトコードを組み上げる唯一にして最大の近道だ。