コードレビューにおいて、最も私の目を曇らせるアンチパターンのひとつが、深いネストを描いた`if`文の山だ。
「入力されたユーザーオブジェクトが有効であり、かつ権限が管理者またはモデレーターであって、さらに特定のフィーチャーフラグが立っている場合のみ処理を実行する」——このような複合条件を、古典的な論理演算子（`&&`や`||`）と泥臭い条件分岐で実装した結果、脳内でのスタックオーバーフローを引き起こしているコードを君たちは日々書いていないか？
Dart 3で導入されたパターンマッチングと論理演算パターン（`&` と `|`）は、単なる「シンタックスシュガー」ではない。これは、コンパイラに対して「我々が検証したいデータの構造と条件」を宣言的に伝えるための強力な武器だ。
今回は、この論理演算パターンを駆使して、複雑なバリデーションロジックを極限までフラット化し、保守性と堅牢性を両立させる設計手法を伝授しよう。
—
なぜ従来の `if` 文と論理演算はスケールしないのか？
実務の現場でよく見かける、APIレスポンスやフォーム入力を検証するコードを思い出してほしい。
// 【アンチパターン】ネストと条件地獄の例
void handleLegacyValidation(Map
if (json.containsKey(‘user’)) {
final user = json[‘user’];
if (user is Map
if (user.containsKey(‘role’) && user.containsKey(‘status’)) {
final role = user[‘role’];
final status = user[‘status’];
if ((role == ‘admin’ || role == ‘moderator’) && status == ‘active’) {
// やっと本処理
print(‘Access Granted’);
return;
}
}
}
}
print(‘Access Denied’);
}
このコードの何が問題か？
1. 認知負荷の高さ: スコープが深く、ガードクロージングが機能していないため、人間がコードの意図をパースするのに脳のメモリを大量消費する。
2. 型安全性の欠如: `dynamic`からのキャストや存在確認が散在し、実行時エラー（TypeError）の温床となっている。
これをDart 3のパターンマッチングと論理演算パターンで書き換えると、世界が変わる。
—.
Dart 3 論理演算パターン（`&` と `|`）の核心
Dart 3のパターンマッチングでは、パターン同士を論理演算子で結合できる。
- ANDパターン (`pattern1 & pattern2`): 両方のパターンにマッチする場合に成立する。
- ORパターン (`pattern1 | pattern2`): いずれかのパターンにマッチする場合に成立する（※両方のパターンで同じ変数にバインドされる必要がある）。
これらを`switch`式や`if case`文と組み合わせることで、複雑な条件分岐を1つのエレガントな式にコンパイルさせることが可能になる。
プロダクションコード例：堅牢な権限・状態バリデーション
実際のWebアプリケーションやフロントエンドの状態管理、APIクライアント層を想定した、極めて実用的なコードを見てほしい。
// ドメインモデルの定義
sealed class UserStatus {}
class Active extends UserStatus {}
class Pending extends UserStatus {}
class Suspended extends UserStatus {}
enum Role { admin, moderator, user, guest }
class UserContext {
final Role role;
final UserStatus status;
final int securityClearance;
const UserContext({
required this.role,
required this.status,
required this.securityClearance,
});
}
/// 複雑なビジネスルールを論理演算パターンで美しく解決するバリデータ
String validateAndAuthorize(UserContext? context) {
// if-case と論理演算パターン（&, |）の融合
if (context case UserContext(
// OR パターン: 管理者 または モデレーター
role: Role.admin | Role.moderator,
// AND パターンとリレーショナルパターン: ステータスがActiveかつクリアランスがレベル2以上
status: Active() & var s,
securityClearance: >= 2,
)) {
return ‘Authorized: 高度な操作が許可されています (${s.runtimeType})’;
}
// 例外的な特権ユーザーの処理（ORの組み合わせ）
else if (context case UserContext(role: Role.admin, securityClearance: >= 5)
| UserContext(status: Active(), securityClearance: >= 10)) {
return ‘Authorized: 特例アクセスが適用されました’;
}
// フォールバック（ガード節）
return ‘Access Denied: 権限またはステータスが不十分です’;
}
void main() {
final user1 = UserContext(role: Role.moderator, status: Active(), securityClearance: 3);
final user2 = UserContext(role: Role.user, status: Pending(), securityClearance: 1);
print(validateAndAuthorize(user1)); // Authorized: 高度な操作が許可されています (Active)
print(validateAndAuthorize(user2)); // Access Denied: 権限またはステータスが不十分です
}
このコードの美しさは、「データの構造検証」と「ビジネスロジックの条件判定」が完全に同期している点にある。`if case` の中で型、値、範囲（`>= 2` などのリレーショナルパターン）を同時に評価し、かつ `&` で条件を結合しているため、余計な一時変数やネストが一切存在しない。
—
コンパイル時評価とパフォーマンスの裏側
「こんなに複雑なパターンマッチングを書くと、実行時のパフォーマンスにペナルティがあるのではないか？」
優秀なテックリードであれば当然そこを懸念するはずだ。結論から言えば、心配無用だ。
DartのAOTコンパイラ（およびJITコンパイラ）は、これらのパターンマッチングを、効率的なジャンプテーブルや最適化された条件分岐ツリーへとコンパイルする。
人間が書いた冗長なネストした `if` 文と同等、あるいはそれ以上に最適化された機械語を出力するため、実行時オーバーヘッドは無視できるレベルである。むしろ、コードの分岐がフラット化されることで、CPUの分岐予測（Branch Prediction）の効率が向上し、パイプラインハザードを軽減するケースすらある。
—
実務で使う際の重要な注意点（アンチパターン回避の心得）
論理演算パターンは強力だが、使い方を誤るとコードベースを「読めない魔術」に変えてしまう。コードレビューで以下の点に注意せよ。
1. ORパターン (`|`) を使う際の変数の束縛制約
ORパターンの両側で、同じ名前の変数を同じ型でバインドしなければならないというDartの言語仕様上の制約がある。異なる構造のデータを無理に `|` で繋ごうとするとコンパイルエラーになるため、複雑すぎる場合は素直に条件を分割せよ。
2. 可読性の限界を見極める
1行の `if case` があまりに長大になる場合は、条件をプライベートなヘルパーメソッド（またはパターンを返すファクトリ）に切り出すか、`switch` 式の網羅性（Exhaustiveness）を利用した構造にリファクタリングすべきだ。
—
チーフアーキテクトからの総括
優れたコードとは、単に動くだけのものではない。「ドメインのルールが、言語の機能を通じて詩のように美しく表現されているコード」のことだ。
Dart 3の論理演算パターンは、君たちのビジネスロジックから不要なノイズを削ぎ落とし、本質的な「条件」だけを浮き彫りにする力を持っている。
明日のコードレビューで、もしネストの深い `if` 文の山を見つけたら、こう言ってやりたまえ。
「おい、ここ、Dart 3の `&` と `|` でフラットに書けるぞ」と。