Dart 3 パターンマッチングがもたらす「if-case」の衝撃：冗長な条件分岐を駆逐し、堅牢な設計を手に入れる
現場のコードレビューで、私は常にこう問いかけている。「その `is` チェックと、その後のキャスト `as`、本当に必要か？」と。
かつての Dart において、複雑なデータ構造を紐解き、特定の条件に合致するかを判定する作業は、まさに「手続き型の苦行」だった。Null安全が導入されてなお、我々は `if (obj != null && obj is Data && obj.id == 100)` といった、冗長で視認性の低いコードを書き続けてきた。
しかし、Dart 3 のリリースによってその時代は終わった。
今回は、新次元の制御構文 `if-case` を中心に、パターンマッチングがいかにしてプロダクトの品質を劇的に向上させるか、Dart VM の挙動を熟知したアーキテクトの視点から徹底解説する。
—
1. なぜ「旧来の if 文」は非効率なのか
まずは、我々が長年書いてきた「前時代的」なコードを振り返ってみよう。APIからのレスポンスを処理する典型的な例だ。
// ❌ 非推奨：冗長で、型安全の恩恵を十分に受けていないコード
void handleResponse(dynamic response) {
if (response is Map
response.containsKey(‘data’) &&
response[‘data’] is Map
response[‘data’][‘id’] != null) {
// ここでようやく実体を使えるが、実行時に再度アクセスが発生する
final id = response[‘data’][‘id’] as int;
print(‘ID: $id’);
}
}
このコードには3つの致命的な問題がある：
1. 冗長性: 構造のチェックとデータの抽出が分離されており、同じパスを何度も辿っている。
2. 実行時のオーバーヘッド: Map のキー検索が何度も走り、VM レベルで非効率なルックアップが繰り返される。
3. 脆弱性: `as int` のような強制キャストは、将来的な型変更に対してランタイムエラーの火種を抱え込む。
—
2. `if-case`：構造の検証と変数の束縛を「アトミック」に行う
Dart 3 の `if-case` は、単なるシンタックスシュガーではない。
「データの形状の検証」と「値の抽出（デストラクト）」を一つのアトミックな操作に統合する。
プロダクション級の `if-case` 実装例
void handleResponse(dynamic response) {
// ✅ 推奨：if-case によるパターンマッチング
// 1. Map であるか
// 2. ‘data’ キーを持ち、その中身が ‘id’ キーを持つ Map か
// 3. ‘id’ の値が int か
// これらを一気に判定し、変数 ‘id’ にバインドする
if (response case {‘data’: {‘id’: int id}}) {
print(‘取得したID: $id’); // このスコープ内では id は完全に型付けされた int
} else {
print(‘不正なレスポンス形式です’);
}
}
何が起きているのか（アーキテクトの視点）
この `if-case` の背後では、Dart AOT コンパイラが最適化された判定ツリーを生成する。
手動で `containsKey` を呼ぶ場合と違い、パターンマッチングは内部的に一度のトラバーサルで構造を確定させる。もし条件に適合しなければ即座に `else` へジャンプする。この「早期失敗（Fail-fast）」の構造が、実行時の分岐予測（Branch Prediction）を助け、パフォーマンスの安定に寄与するのだ。
—
3. 実務で勝つための「ガード句（when）」の活用
単に構造が一致するだけでなく、その中の値が特定の条件を満たす必要がある場合も多い。そこで真価を発揮するのが `when` 句だ。
/// ユーザー権限に応じたUIアクションの判定
void authorizeAction(Map
// 構造チェック + 条件チェックを一行で完結させる
if (userJson case {‘role’: ‘admin’, ‘points’: int p} when p > 1000) {
print(‘プレミアム管理者として全機能を解放します。’);
} else if (userJson case {‘role’: ‘user’, ‘id’: String uid}) {
print(‘一般ユーザー($uid)としてログインしました。’);
}
}
ここでのポイントは、変数 `p` を抽出した直後に `when` でその値を使用している点だ。
これまでの「if文の中にif文を重ねる」ネスト地獄（Arrow Code）を完全に排除できていることがわかるだろう。
—
4. Null安全とパターンマッチングの融合
フロントエンド開発において、最も頻出するパターンは「Nullかもしれない値」のハンドリングだ。`if-case` はここでも威力を発揮する。
void updateProfile(String? nickname) {
// nickname が non-null かつ 空文字でない場合のみ処理
if (nickname case String name when name.isNotEmpty) {
print(‘プロフィールの名前を $name に更新します’);
} else {
print(‘有効な名前を入力してください’);
}
}
従来の `if (nickname != null && nickname.isNotEmpty)` と比較して、`case String name` と型を指定することで、その後のスコープで `name` は非Nullの `String` として確定する。 これは Dart VM のプロモーション（型昇格）をより明示的かつ堅牢にした形と言える。
—
5. テクニカルリードが教える「設計の極意」
`if-case` を使いこなすための、私からのアドバイスを 3 つにまとめる。
① 「型」をパターンに語らせろ
`case {‘status’: 200}` と書くよりも、可能であれば Sealed Class を定義し、`case Success(data: var d)` と書くべきだ。Sealed Class とパターンマッチングの組み合わせこそが、Dart 3 における最強の型安全ガードとなる。
② 計算コストを意識せよ
パターンマッチングの中で重いメソッドを呼び出す `when` 句を書くのは避けろ。パターンマッチングは「構造の合致」を高速に判定するためのものだ。
③ 読み手に意図を伝えろ
`if-case` は「特定の特定のケースにのみ関心がある」という意思表示だ。もし、すべての列挙型（Enum）を網羅的に処理する必要があるなら、`if-case` ではなく `switch` 文を使え。`switch` は網羅性チェック（Exhaustiveness checking）が働き、実装漏れをコンパイルエラーで防いでくれる。
—
結論：コードは「書くもの」ではなく「語るもの」であるべきだ
Dart 3 のパターンマッチング、とりわけ `if-case` は、単なる短縮記法ではない。それは、データの「構造」と「意味」をコード上で一致させるための強力な武器だ。
冗長な `if` 文、不安を煽る強制キャスト、そして読み手を惑わすネストを今日から捨て去ろう。
`if-case` を使いこなし、VM が喜ぶ効率的で、同僚が驚くほど美しいプロダクションコードを書き上げてほしい。
「優れたコードは、説明を必要とせず、その構造自体が正しさを証明する。」
これが、Dart 3 を掌握した者の進むべき道だ。