Dart 3パターンマッチングの真価：if-elseの呪縛から脱却し、認知負荷をゼロにするコード設計
コードレビューをしていて、次のような「ネストの深いif-elseの山」に出くたことはないだろうか。
// 良くあるアンチパターン：条件分岐の迷宮
String getActionDescription(Map
if (json.containsKey(‘type’)) {
if (json[‘type’] == ‘user’) {
if (json.containsKey(‘data’)) {
var data = json[‘data’];
if (data is Map && data.containsKey(‘status’)) {
if (data[‘status’] == ‘active’) {
return ‘Active User: ${data[‘name’]}’;
} else {
return ‘Inactive User’;
}
}
}
} else if (json[‘type’] == ‘system’) {
return ‘System Event’;
}
}
return ‘Unknown’;
}
このコードの何が問題か。「データの形（形状）」を検証するロジックと、「値」を評価するロジックが手続き的に絡み合い、人間が脳内でパースしなければならないコンテキスト（認知負荷）が限界値を超えている点だ。
Dart 3で導入されたパターンマッチング（Pattern Matching）とDestructuring（分解）は、単なるシンタックスシュガーではない。これは「データの構造そのものを型安全にコードの見た目に直結させる」ためのパラダイムシフトである。
今回は、フロントエンドの状態管理や複雑なAPIレスポンスのハンドリングにおいて、なぜ従来のif-elseを捨ててパターンマッチングを採用すべきなのか、その極限の知見をコードレビューの視点からロジカルに伝授する。
—
1. なぜif-elseはメンテナンス性を破壊するのか？
従来のif-elseや`switch`文は、「文（Statement）」ベースであった。そのため、条件を評価するたびに一時変数を生み出し、型キャスト（`as`）や`is`チェックのボイラープレートを強制される。
特にフロントエンドや非同期API連携では、サーバーから送られてくる不確定なJSONや、UIの複雑な状態（Loading, Success, Error, 以及それぞれのサブ状態）をハンドリングする際、if-elseの深さはバグの温床となる。
- 変更に弱い: JSONのスキーマが1階層深くなっただけで、コードの全行を書き直す必要がある。
- 網羅性の欠如 (Exhaustiveness): 新しい状態を追加した際、どこかで`else`がそれを闇に葬り、コンパイラが警告してくれない。
- 意図の乖離: 「データがこの構造であることの確認」と「処理の実行」が混ざり合い、コードの意図が隠蔽される。
—
2. Dart 3 パターンマッチングによる解法：構造をコードで「描く」
Dart 3以降、`switch`は「式（Expression）」として機能し、強力なパターンマッチングを手に入れた。これにより、「データの形をそのままパターンとして記述する」ことが可能になる。
実際のプロダクションコードを想定し、APIからの非同期レスポンス（UIの状態管理）を美しくハンドリングする設計を見てみよう。
コピペで使えるプロダクションコード例
以下のコードは、複雑なAPIのレスポンスや状態を、パターンマッチングを用いて完全に制御下置いた堅牢な実装だ。
import ‘package:flutter/foundation.dart’;
// 1. ドメインモデルの定義（密封クラス: Sealed classによる網羅性確保）
sealed class ApiResponse
class Loading
class Success
final T data;
final DateTime timestamp;
Success(this.data, this.timestamp);
}
class Error
final int errorCode;
final String message;
Error(this.errorCode, this.message);
}
// 2. ユーザーデータの構造
class UserData {
final String id;
final String name;
final bool isAdmin;
UserData({required this.id, required this.name, required this.isAdmin});
}
// 3. パターンマッチングを活用したビューモデル・レンダリングロジック
String resolveUiState(ApiResponse
// Dart 3の Switch Expression と パターンマッチング
return switch (response) {
// Loading状態のハンドリング
Loading
// Success状態かつ、特定の条件（管理者の場合）をオブジェクト分解(Destructuring)で一撃で抽出
Success(data: UserData(isAdmin: true, :var name)) =>
‘特権管理者アクセスのダッシュボードを表示: $name’,
// 通常のSuccess状態（オブジェクトのプロパティを直接バインド）
Success(data: UserData(isAdmin: false, :var name), :var timestamp) =>
‘ようこそ、$name さん (最終同期: ${timestamp.toIso8601String()})’,
// エラーコードに応じた分岐（ガード節 / when句の活用）
Error(errorCode: >= 500 && < 600, :var message) =>
‘サーバーサイドエラーが発生しました: $message’,
Error(:var errorCode, :var message) =>
‘クライアントエラー [$errorCode]: $message’,
};
}
// 動作確認用メイン関数
void main() {
final res1 = Success(
UserData(id: ‘u_001’, name: ‘Alice’, isAdmin: true),
DateTime.now(),
);
final res2 = Error(503, ‘Service Unavailable’);
print(resolveUiState(res1));
// 出力: 特権管理者アクセスのダッシュボードを表示: Alice
print(resolveUiState(res2));
// 出力: サーバーサイドエラーが発生しました: Service Unavailable
}
—
3. このコードが「美しい」理由：テクニカルリードの視点
上記のコードには、Dartの言語仕様の深淵を理解した上での設計思想が随所に込められている。
① 網羅性チェック（Exhaustiveness Checking）の強制
`sealed class`と`switch`を組み合わせることで、Dartのコンパイラは「すべての可能性がハンドリングされているか」を静的解析時にチェックする。もし将来、新しい状態（例: `Maintenance`）が追加された場合、コンパイラエラーが発生するため、開発者がハンドリング漏れを起こす余地を完全に排除できる。
② オブジェクト分解（Object Patterns & Destructuring）
`Success(data: UserData(isAdmin: true, :var name))` の部分を見てほしい。
これは、`Success`オブジェクトの `data` プロパティを取り出し、さらにその中の `UserData` の `isAdmin` が `true` であることを検証しつつ、`name` 変数をその場でバインドしている。
従来のコードであれば、数行にわたる `is` キャストとプロパティアクセスが必要だったものが、「データの階層構造をそのままコードのパターンとして視覚化」することに成功している。
③ 関係演算子パターン（Relational Patterns）
`Error(errorCode: >= 500 && < 600, :var message)` では、パターン内に比較演算子（`>=`, `<`）を直接埋め込んでいる（Relational Patterns）。これにより、エラーコードのレンジ判定を行うためにわざわざ `if (code >= 500)` と書く必要がなくなり、宣言的なコード記述が可能になっている。
—
4. パフォーマンスとコンパイル時の挙動に関する注意点
「これだけ複雑なパターンマッチングをすると、実行時コスト（パフォーマンス）が高いのではないか？」という懸念を持つシニアエンジニアもいるだろう。
ここでDart VMの裏側の動きを解説する。
1. 静的ディスパッチと最適化: Dartの `switch` 式は、単純な連続比較（if-elseの連鎖）にコンパイルされるだけでなく、条件の特性（整数値の範囲など）によってはジャンプテーブル（Jump Table）や最適化された決定木（Decision Tree）にコンパイルされる。
2. AOTコンパイル時のインライン化: FlutterのAOT（Ahead-Of-Time）コンパイラは、型パターンやプロパティへのアクセスを極限までインライン化し、不要なボクシング（Box化）やオブジェクト生成を排除する。
3. 注意点（過剰なパターンのネスト）： パターンを何重にも深くネストさせすぎると、コンパイラが最適な決定木を生成できず、評価コストが増大する場合がある。原則として、パターンのネストは最大2階層までに留めるべきである。もしそれ以上に複雑になる場合は、ドメインモデル側をフラットに設計し直すか、責任を別関数に委譲する設計（Single Responsibility Principle）を適用せよ。
—
5. まとめ：明日からのコードレビューで意識すべきこと
if-elseの海に溺れたコードは、開発チームの生産性をじわじわと蝕むガンだ。
もしあなたのプロジェクトで、次のようなコードを見かけたら、即座にリファクタリングを命じてほしい。
- `is` チェックの後にすかさずキャスト（`as`）しているコード
- JSONやAPIレスポンスのパースにおいて、`if (map.containsKey(…))` が3階層以上続いているコード
- 状態の追加漏れが起きやすい巨大な `if-else` 連鎖
「データの構造をそのままコードの形にする」。
Dart 3のパターンマッチングを使いこなせば、あなたの書くコードは驚くほど宣言的になり、バグの入り込む余地は消え去る。
次のプルリクエストから、ボイラープレートまみれのif-elseを美しい `switch` 式に置き換えてみせよう。チームメイトはその圧倒的なコードの美しさと保守性の高さに驚嘆するはずだ。