Dart 3 パターンマッチングの真価：Extension Typesによるドメイン表現の極限
コードレビューをしていて、次のようなコードに出くくしたことはないだろうか。
// よくある冗長なAPIレスポンスのハンドリング
if (response[‘status’] == ‘success’) {
final data = response[‘data’] as Map
return Success(User.fromJson(data));
} else if (response[‘status’] == ‘error’) {
final error = response[‘error’] as String;
return Failure(error);
} else {
return Loading();
}
Webフロントエンドや非同期API連携の現場において、JSONのパース結果やUIの状態分岐はバグの温床になりやすい。Dart 3で導入されたパターンマッチング（Pattern Matching）と網羅性チェック（Exhaustiveness Checking）は、このボイラープレートを駆逐するための強力な武器だ。
しかし、素のままで複雑なドメインモデルをパターンマッチングさせようとすると、API側の都合に引きずられた脆弱なコードになりがちである。ここで、Dart 3.3以降で導入された Extension Types（拡張型） を組み合わせる。
今回は、コンパイル時のゼロコスト抽象化を維持したまま、パターンマッチングの表現力を爆発的に拡張するプロダクション設計パターンを伝授する。
—
なぜ普通のクラスや拡張メソッドでは不十分なのか？
まず、アーキテクチャの共通認識を持とう。
フロントエンドの状態管理やAPIクライアント層において、パフォーマンスは命だ。
- 通常のクラス（`class`）: ヒープ上にインスタンスがアロケートされ、GC（ガベージコレクション）に負荷がかかる。
- 拡張メソッド（`extension`）: メソッドを生やすことはできるが、型自体を変化させることはできないため、パターンマッチングの対象（`switch` 式の式）として構造化データを美しく分解できない。
Extension Types (`extension type`) は、既存の型（多くは `Map` や `String`、プリミティブ型など）を、実行時オーバーヘッドなし（Zero-cost abstraction）で別の型としてラップする。Dart VMのAOTコンパイラは、これをコンパイル時に元の型へと完全にインライン展開する。
つまり、「実行時はただの軽量なデータ構造でありながら、開発時は厳密な型安全性とパターンマッチングに最適化されたAPI」 を構築できるのだ。
—
実践：APIレスポンスを型安全に支配するプロダクションコード
以下のコードは、WebAPIからの非同期レスポンスをExtension Typesで包み込み、Dart 3の `switch` 式とパターンマッチングで完全に制御する実用的な設計例である。
// ==========================================
// 1. ドメイン層: Extension Typeによる型定義
// ==========================================
/// APIレスポンスの基盤となる生データ（Map）をラップするExtension Type
extension type ApiResponse(Map
// コンストラクタで簡易的なバリデーションを行うことも可能（ゼロコスト）
ApiResponse.success(Map
: this({‘status’: ‘success’, ‘data’: data});
ApiResponse.error(String message)
: this({‘status’: ‘error’, ‘message’: message});
ApiResponse.loading()
: this({‘status’: ‘loading’});
// パターンマッチング用のゲッター群（構造化分解をサポート）
String get status => _raw[‘status’] as String? ?? ‘unknown’;
Map
String? get errorMessage => _raw[‘message’] as String? ;
}
// ユーザーエンティティ
class User {
final String id;
final String name;
const User({required this.id, required this.name});
factory User.fromJson(Map
id: json[‘id’] as String,
name: json[‘name’] as String,
);
}
// ==========================================
// 2. UI / プレゼンテーション層: パターンマッチングの適用
// ==========================================
String renderUiState(ApiResponse response) {
// Dart 3のスイッチ式とパターンマッチング、網羅性チェックの組み合わせ
return switch (response) {
// 1. 成功ステータスかつ、dataが存在し、パース可能な場合
(ApiResponse r) when r.status == ‘success’ && r.data !=خص =>
_handleSuccess(r.data!),
// 2. エラーメッセージが含まれている場合
(ApiResponse r) when r.status == ‘error’ =>
‘Error occurred: ${r.errorMessage ?? “Unknown error”}’,
// 3. ローディング中
(ApiResponse r) when r.status == ‘loading’ =>
‘Loading data, please wait…’,
// 4. 不正なフォーマット
_ => ‘Invalid state received from API.’,
};
}
String _handleSuccess(Map
final user = User.fromJson(data);
return ‘Welcome back, ${user.name} (ID: ${user.id})!’;
}
// ==========================================
// 3. 実行シミュレーション
// ==========================================
void main() {
// モックAPIレスポンス
var res1 = ApiResponse.success({‘id’: ‘U-9981’, ‘name’: ‘Alice Architect’});
var res2 = ApiResponse.error(‘Unauthorized access’);
var res3 = ApiResponse.loading();
print(renderUiState(res1)); // 出力: Welcome back, Alice Architect (ID: U-9981)!
print(renderUiState(res2)); // 出力: Error occurred: Unauthorized access
print(renderUiState(res3)); // 出力: Loading data, please wait…
}
—
アーキテクチャ上の重要な注意点とパフォーマンスの真実
コードレビューでよくある誤解として、「Extension Typeを使えば、どんな複雑なオブジェクト指向設計もメモリ効率よく実現できる」というものがある。しかし、Dart VMの挙動を理解している我々アーキテクトは、次のトレードオフを常に意識しなければならない。
1. 実行時コストは本当に「ゼロ」か？
Extension Type自体は、コンパイル時に背後の型（今回の場合は `Map
ただし、内部で `Map` やダイナミックなキャスト（`as Map
パフォーマンスがクリティカルなループ内や高頻度で呼ばれるウィジェットのビルドメソッド内では、生データのキャストを最小限に抑える設計にすること。
2. パターンマッチングにおける網羅性と `when` 句の罠
上記のコードでは `when` 句を使用しているが、Dartのコンパイラは `when` 句の中身（カスタムゲッターの評価結果）まで含めた網羅性チェック（Exhaustiveness Checking）を完全には静的解析できない場合がある。
もし、将来的にAPIのステータスに `’maintenance’` が追加された場合、`_ =>` のフォールバックに落ちてしまい、コンパイルエラーによる検知が漏れるリスクがある。
より堅牢な設計を目指すならば、Extension Typeと Sealedクラス（あるいはSealed記録型） を組み合わせるべきである。
—
チームへの展開：シニアエンジニアからの提言
実務でこのテクニックを導入する際は、以下のガイドラインをチームに徹底してほしい。
1. APIレスポンスの「生データへの依存」をカプセル化する:
コンポーネント側で直接 `response[‘status’]` のようなマジックストリングを触らせず、必ずExtension TypeでラップしたセマンティックなAPIを経由させる。
2. 過剰な抽象化を避ける:
一度限りの小さな処理のためにExtension Typeを作ると、逆にコードの認知負荷が上がる。JSONパース結果の分岐や、複雑な状態機械（State Machine）のハンドリングなど、「バグが起きたときのインパクトが大きい場所」に限定して投入せよ。
Dart 3のパターンマッチングとExtension Typesを使いこなせば、動的言語のような柔軟性を持ちながら、静的言語の最高峰であるかのような堅牢なコードベースが手に入る。
明日のコードレビューから、冗長な `if-else` をこの美しいパターンマッチングに置き換えていこう。