Dart 3 オブジェクトパターンの深淵：ゲッター呼び出しの隠れたコストとランタイムの罠
Dart 3におけるパターンマッチングとデストラクチャリング（分解）は、言語の表現力を劇的に引き上げた。特に`switch`式や`case`節、そして`if-case`文におけるオブジェクトパターン（Object Patterns）は、冗長なボイラープレートを消し去り、宣言的なドメインモデリングを可能にする。
だが、チーフアーキテクトとして警告しておかねばならない。
「パターンマッチングは、単なるデータの参照ではない。それはコードの実行であり、隠れた関数呼び出しの連鎖である」
表面的な構文の美しさに惑わされ、ランタイムの挙動（Dart VMの最適化、メモリモデル、そしてイベントループの非同期コンテキスト）を無視したコードを書けば、システムは予期せぬ副作用、パフォーマンスの劣化、あるいは追跡困難なバグの温床となる。
本稿では、オブジェクトパターンがプロパティを分解する際の「真のメカニズム」を、コンパイラとVMの挙動から徹底的に解剖する。
—
1. コンパイルとランタイムの真実：オブジェクトパターンは「ゲッターの乱数打ち」である
次のコードを見てほしい。一見すると、単にオブジェクトのフィールドを「取り出している」ように見えるだろう。
class NetworkResponse {
final int statusCode;
final String rawBody;
NetworkResponse(this.statusCode, this.rawBody);
// 算出プロパティ（副作用の可能性がある、またはコストが高い処理）
String get parsedBody {
print(‘>>> [VM TRACE]Heavy JSON parsing invoked!’);
return _expensiveParse(rawBody);
}
String _expensiveParse(String body) => ‘{“parsed”: $body}’;
}
void handleResponse(Object response) {
if (response is NetworkResponse case NetworkResponse(statusCode: 200, parsedBody: var body)) {
print(‘Success: $body’);
}
}
シニアエンジニアなら、このコードの何が危険か直感できるはずだ。
Dartのオブジェクトパターン `NetworkResponse(statusCode: 200, parsedBody: var body)` は、シンタックスシュガーではなく、明示的なゲッター呼び出しの命令にコンパイルされる。
VMの視点：何が起きているか？
1. 型ガードの通過: `response is NetworkResponse` により、CFA（Class Hierarchy Analysis）に基づいた型チェックが走る。
2. マッチングの順序: Dartコンパイラ（AOT/JIT）は、パターン内のフィールド評価順序を保証する。通常は記述順、あるいは最適化ヒューリスティクスに従うが、ガード条件や失敗可能性（refutability）のあるパターンにおいて、ゲッターは複数回評価されるリスクを持つ。
3. 副作用の二重発火: 最悪なのは、マッチングの途中で評価が失敗した場合や、複数の `case` を評価する `switch` 文の構造だ。
void evaluateMultipleCases(NetworkResponse res) {
switch (res) {
// ここで parsedBody のゲッターが呼ばれる
case NetworkResponse(statusCode: 200, parsedBody: var b):
print(‘200: $b’);
// もし上のケースが不成立の場合、switchの構造や最適化戦略によっては
// ゲッターが再度評価される、あるいは不必要なコストが発生する可能性がある
case NetworkResponse(statusCode: 500, parsedBody: var b):
print(‘500: $b’);
}
}
Dart VMのJIT/AOTコンパイラ（特にKernelからCAFE/Precompilerパイプラインを通る際）は、純粋性（Purity）の解析を行わない限り、ユーザー定義の `get` アクセサを「副作用のない安全なメモリ読み取り」とはみなさない。したがって、コンパイラはゲッターのインライン化や共通部分式削除（CSE）を勝手には行えないのだ。
—
2. 副作用を持つプロパティを分解する際の「致命的な落とし穴」
オブジェクトパターンの最も危険なアンチパターンは、「ゲッター内部で状態を変更する（副作用を持つ）」あるいは「I/Oや重い計算を行う」プロパティをパターン内に直接記述することだ。
以下の実例を見てほしい。セキュリティ監査や高スループットなイベント処理システムでやりがちなミスだ。
class SecureTokenContext {
int _accessCount = 0;
String get token {
_accessCount++; // 状態の改変（副作用）
if (_accessCount > 3) {
throw StateError(‘Security Alert: Token access limit exceeded!’);
}
return ‘AUTH_SECRET_XYZ’;
}
}
void processRequest(Object context) {
// パターンマッチングでトークンを取り出そうとする
if (context is SecureTokenContext case SecureTokenContext(token: ‘AUTH_SECRET_XYZ’)) {
print(‘Access granted.’);
} else {
print(‘Access denied.’);
}
}
このコードを実行するとどうなるか？
もしマッチングの評価過程でVMが内部的にプロパティを複数回評価したり、あるいは将来の言語仕様の変更・最適化パスの変更によって評価順序が入れ替わったりした場合、`_accessCount` のインクリメント回数が意図せぬものになり、突然 `StateError` が爆発する。
> Architecture Note:
> オブジェクトパターンは「イミュータブルで、副作用のない、純粋なデータ構造（Value Objects）」を分解するために設計されている。
> ドメインモデルに `get` で隠蔽されたロジック（遅延初期化、ロギング、カウンター、外部リソースへのアクセス）が存在する場合、パターンマッチングの右辺（あるいはガード内）に直接置くべきではない。
—
3. 防壁を構築する：安全なデストラクチャリングのプラクティス
では、副作用を持つプロパティや重い演算プロパティを持つオブジェクトを安全に扱うにはどうすればよいのか？ 答えは「明示的なローカル変数への退避（Value Binding）」である。
パターンマッチングの前に一度ローカル変数にスナップショットを撮り、その「値」に対してパターンを適用する。
void processRequestSafely(Object context) {
if (context is SecureTokenContext) {
// 1. 副作用を伴うゲッターを「1回だけ」安全なスコープで評価する
final currentToken = context.token;
// 2. 取得済みの不変値に対してパターンマッチング（または単純な比較）を行う
if (currentToken == ‘AUTH_SECRET_XYZ’) {
print(‘Access granted safely. Count preserved.’);
} else {
print(‘Access denied.’);
}
}
}
このアプローチにより、以下のメリットが生まれる：
1. 評価回数の完全な制御: ゲッターの呼び出しが確実に1回であることが保証される。
2. イベントループと非同期コンテキストの保護: マイクロタスクキューやイベントキューの処理中において、意図しない例外の発生による制御フローの崩壊を防ぐ。
3. VMの最適化恩恵: ローカル変数（Local Variable）はレジスタまたはスタック上の高速なスロットに割り当てられるため、後続の比較処理のパフォーマンスが最大化される。
—
4. 高度なパターン：ガード節（`when`）における評価順序の罠
Dart 3のパターンマッチングでは、`when` 節を使ったガード条件を指定できる。ここでもゲッターの評価に関する厳密な知見が必要だ。
class Transaction {
final double amount;
Transaction(this.amount);
bool get isValid {
print(‘isValid evaluated’);
return amount > 0;
}
}
void inspectTransaction(Transaction tx) {
switch (tx) {
case Transaction(amount: var a) when tx.isValid && a < 1000:
print('Small valid transaction: $a');
break;
default:
print('Other');
}
}
Dartの評価戦略において、論理演算子 `&&` は短絡評価（Short-circuit evaluation）を行う。
しかし、パターンマッチングの評価フェーズと `when` 節の評価フェーズの間には、明確な順序の境界が存在する。
1. まず、パターン `Transaction(amount: var a)` が評価され、フィールド `amount` がバインドされる。
2. 次に、`when` 節の式 `tx.isValid && a < 1000` が評価される。
もしパターン側でゲッターをバインドしようとし、さらに `when` 節で別のゲッターを叩くような複雑な構造を作ると、コンパイラが生成するジャンプテーブルや分岐最適化（Jumpswitch/Type-test optimization）の効率が落ち、VMのプロファイルガイド最適化（PGO）の効果が薄れる。
複雑な条件分岐は、パターンマッチングにすべてを詰め込むのではなく、一度ガード用のプレディケート（述語関数）やローカル変数に整理してから適用するのが、大規模アーキテクチャにおける鉄則である。
---
結言
Dart 3のオブジェクトパターンは、コードベースを洗練させる強力な武器だ。しかし、それは魔法ではない。
すべての構文の裏側には、Dart VMのメモリ管理、スタックフレームの構築、そしてCPUの実行サイクルが存在する。
- ゲッターは関数呼び出しであるという事実を忘れないこと。
- 副作用のあるプロパティをパターンの直接の標的にしないこと。
- 複雑な評価は必ず事前にローカル変数へスナップショットを撮ること。
この極限の知見を脳裏に焼き付け、ランタイムと調和した堅牢なコードを構築せよ。それが、真にDartを掌握したエンジニアの姿である。