Dart 3パターンマッチングで制す：再帰的木構造の走査とイミュータブル変換の極意
コードレビューをしていて、次のようなコードに出くわすことはないだろうか。
// 良くあるアンチパターン：型チェックとダウンキャストの嵐
dynamic processNode(dynamic node) {
if (node is TextNode) {
return handleText(node.text);
} else if (node is ElementNode) {
final children = node.children.map((c) => processNode(c)).toList();
return handleElement(node.tag, children);
}
throw StateError(‘Unknown node type’);
}
動的型チェック、`dynamic` や `is` による煩雑な分岐、そして可変なリスト操作。これらは保守性を殺し、ランタイムエラーの温床となる。フロントエンドの状態管理、コンポーネントツリーの構築、あるいはJSONやGraphQLの複雑なレスポンスをドメインモデルに射影する際、我々は常に「再帰的な木構造」のハンドリングに直面する。
Dart 3で導入されたパターンマッチング（Pattern Matching）と網羅的チェック（Exhaustiveness Checking）は、この永遠の課題に対する決定的なパラダイムシフトをもたらした。
本記事では、Dartコアの挙動を知り尽くしたアーキテクトの視点から、パターンマッチングを駆使して「堅牢」「高速」「美観」を極めた木構造の走査・変換アルゴリズムを解説する。
—
1. なぜ従来のVisitorパターンや`is`チェックでは不十分なのか
オブジェクト指向の教科書では、木構造の走査には決まって「Visitorパターン」が推される。しかし、現代のWebアプリケーション開発やコンポーネント設計において、Visitorパターンは過剰にボアラープレートを増やし、データ構造と操作ロジックの結合度を高めてしまう。
一方、`switch` 式とパターンマッチングを使えば、「データ構造（Algebraic Data Types: ADT）」と「振る舞い（アルゴリズム）」を完全に分離しながら、コンパイラによる厳密な型安全性を担保できる。
Dart 3のコンパイラ（cfe: Common Front End）は、`switch` 式の網羅性を静的に検証する。もし将来、新しいノードの種類を追加し忘れた場合、コンパイルエラーとして即座に検知される。ランタイムエラーの余地は、この瞬間完全に消滅する。
—
2. プロダクションコード：抽象構文木（AST）のイミュータブル変換
実務を想定し、マークダウンやUIコンポーネントの表現を模した「再帰的な木構造（AST）」を定義しよう。
ここでは、ノードの評価（Evaluation）と、特定の条件に基づくノードの置換（Transformation）を実装する。
// — 1. 代数的データ型（ADT）としてのノード定義 —
sealed class UiNode {}
class TextNode extends UiNode {
final String text;
TextNode(this.text);
}
class ElementNode extends UiNode {
final String tag;
final Map
final List
ElementNode(this.tag, this.attributes, this.children);
}
class ComponentNode extends UiNode {
final String name;
final Map
ComponentNode(this.name, this.props);
}
// — 2. パターンマッチングによる再帰的トランスフォーマー —
/// ツリー全体を走査し、特定の条件に合致するノードを置換・最適化する関数
UiNode transformTree(UiNode node, UiNode Function(UiNode) transformer) {
// まず自身を変換（ポストオーダー走査の例：子を先に処理する場合は順序を入れ替える）
final transformedSelf = transformer(node);
// パターンマッチングによる再帰的な子要素の展開
return switch (transformedSelf) {
// 終端ノード（子を持たない）はそのまま返す
TextNode() || ComponentNode() => transformedSelf,
// 子を持つコンテナノードは、イミュータブルに子を再帰変換する
ElementNode(:var tag, :var attributes, :var children) => ElementNode(
tag,
attributes,
// リスト内包表記と再帰呼び出しの組み合わせ
children.map((child) => transformTree(child, transformer)).toList(),
),
};
}
// — 3. 実践的なユースケース：特定のテキストをマスクする処理 —
UiNode securityMaskTransformer(UiNode node) {
return switch (node) {
// オブジェクトパターンとプロパティマッチング
TextNode(text: var t) when t.contains(‘SECRET’) => TextNode(t.replaceAll(‘SECRET’, ”)),
// マッチしない場合は元のノードを維持
_ => node,
};
}
void main() {
// ツリーの構築
final root = ElementNode(
‘div’,
{‘class’: ‘container’},
[
TextNode(‘Welcome to the dashboard.’),
ElementNode(
‘p’,
{},
[TextNode(‘User API Key: SECRET_12345’)],
),
ComponentNode(‘UserProfile’, {‘userId’: 42}),
],
);
// 変換の実行
final securedRoot = transformTree(root, securityMaskTransformer);
// 結果の検証（ダンプ出力）
_dumpTree(securedRoot, 0);
}
void _dumpTree(UiNode node, int depth) {
final indent = ‘ ‘ depth;
switch (node) {
case TextNode(:var text):
print(‘$indent[TextNode] “$text”‘);
case ElementNode(:var tag, :var children):
print(‘$indent[ElementNode] <$tag>‘);
for (final child in children) {
_dumpTree(child, depth + 1);
}
case ComponentNode(:var name, :var props):
print(‘$indent[ComponentNode] <$name> props: $props’);
}
}
このコードの優れた設計ポイント
1. 網羅性（Exhaustiveness）の担保: `transformTree` 内の `switch` 式では、`UiNode` のサブタイプがすべて網羅されているため、`default` 句を書く必要がない。新しいノード（例: `CommentNode`）を追加した瞬間、Dartコンパイラがエラーを吐き、対応漏れを防ぐ。
2. 完全なイミュータビリティ: 既存のノードオブジェクトを破壊的変更（mutate）せず、常に新しいインスタンスを生成して返す。これにより、FlutterのWidgetツリーや状態管理（Riverpod / BLoCなど）における参照比較の最適化（`==` や `identical`）が破綻しない。
3. ガード節（Guards）の活用: `securityMaskTransformer` における `when t.contains(‘SECRET’)` のように、パターンマッチングと条件分岐をエレガントに融合させている。
—
3. パフォーマンスとVMの裏側：知っておくべき最適化の罠
テクニカルリードとして、パフォーマンスに関する重要な知見を共有しておこう。
Dart VMやAOTコンパイラ（dart2native）において、パターンマッチングは非常に高度に最適化される。多くの場合、従来の `is` チェックの連続よりもジャンプテーブル（Jump Table）や効率的な型タグ比較にコンパイルされるため、実行速度のペナルティはほぼない。
しかし、再帰アルゴリズムにおけるメモリとスタックオーバフローには注意が必要だ。
⚠️ スタックオーバフロー対策（Deep Treeの罠）
数万件のネストを持つ巨大なJSONやDOMツリーに対し、単純な再帰（Recursion）を行うと、Dartのコールスタック（Call Stack）を食いつぶし、`StackOverflowError` を引き起こす。
プロダクションコードで数千・数万の深さに達する可能性がある場合は、再帰を「明示的なスタック（Stack）を使った非再帰的走査（Trampoline / Iterative）」に書き換えるべきだ。
// スタックを用いた安全な非再帰的ツリー走査のスケルトン
void traverseIteratively(UiNode root) {
final stack =
while (stack.isNotEmpty) {
final currentNode = stack.removeLast();
// パターンマッチングで安全に処理
switch (currentNode) {
case TextNode():
// 葉の処理
break;
case ElementNode(:var children):
// 子をスタックに逆順で積む（左から右へ処理するため）
stack.addAll(children.reversed);
case ComponentNode():
// コンポーネントの処理
break;
}
}
}
フロントエンドのUIコンポーネントツリーや通常のAPIレスポンスであれば、通常は深さが数十程度に収まるため再帰で十分エレガントに記述できるが、「ユーザーが任意の構造をアップロードできるパーサー」などを実装する場合は、必ず非帰納的アプローチを検討してほしい。
—
4. まとめ
Dart 3のパターンマッチングは、単なる「シンタックスシュガー」ではない。それは、複雑なドメインモデルや階層データを安全に、宣言的に、そして美しくハンドリングするための強力な思想である。
- `switch` 式とオブジェクトパターンにより、`is` キャストや `dynamic` の悪夢から脱却する。
- コンパイラの網羅性チェックにより、機能拡張時のデグレを構造的に予防する。
- イミュータブルなデータ変換を徹底し、予測可能なアーキテクチャを構築する。
日々のコードレビューで、もし `if (node is …)` の山を見つけたら、この記事で紹介したパターンマッチングによるリファクタリングをチームに提案してほしい。コードベースの気品と堅牢性が劇的に向上することを約束しよう。