概要

条件分岐はコード内で最も多く使われる制御構造だが、
乱用すると分岐がスパゲッティ化し、ロジックが不透明化する。

JavaScriptでは if-else, switch, 三項演算子, オブジェクトリテラル, 関数ディスパッチ など、
条件制御の手法が豊富にある。重要なのは、**分岐そのものより「分岐の責務と配置」**である。

本稿では、条件分岐の使い分け、分岐の抽象化、選択の最適戦略、設計判断の基準を整理して提示する。

1. 基本：`if / else` の役割

if (status === 'active') {
  activate();
} else if (status === 'disabled') {
  disable();
} else {
  fallback();
}

✅ 2〜3条件までなら直感的で読みやすい
❌ 条件が多くなるとネスト・重複・可読性の低下が発生

2. `switch` による明示的分岐

switch (type) {
  case 'circle':
    drawCircle(); break;
  case 'square':
    drawSquare(); break;
  default:
    drawUnknown(); break;
}

✅ 同一キーに対する分岐では switch が効果的
❌ コード量が増えやすく、式として扱えない（戻り値がない）

3. オブジェクトリテラルによるディスパッチ制御

const drawStrategies = {
  circle: () => drawCircle(),
  square: () => drawSquare(),
  default: () => drawUnknown()
};

const draw = (type) => (drawStrategies[type] || drawStrategies.default)();

✅ 条件をデータとして扱える → マップベースの分離
✅ 関数の切り替えが構造的・スケーラブルに記述可能

4. 関数型分離による選択制御

function draw(type) {
  const strategyMap = new Map([
    ['circle', drawCircle],
    ['square', drawSquare]
  ]);

  const fn = strategyMap.get(type) ?? drawUnknown;
  fn();
}

✅ 関数を値として扱うことで、ロジックの切り替えを柔軟に管理
✅ Map によってランタイム構築・条件追加が容易

5. 戦略的に選択する条件分岐構造

条件の数	状況	推奨構文
1〜3個	単純条件分岐	`if / else`
複数定数	同一キーに対する処理切り替え	`switch` またはオブジェクトリテラル
動的登録	ランタイムに関数を登録	`Map + 関数ディスパッチ`
スタイル/クラス切り替え	UI構造の動的変更	オブジェクトリテラル or 条件式展開

設計判断フロー

① 条件の数は？ → 多いならデータ構造で管理すべき

② 条件は静的か動的か？ → 動的ならMapなどを活用

③ 条件に副作用が含まれるか？ → 関数として分離

④ 処理が複雑になっていないか？ → 戦略パターンの導入を検討

⑤ switch や if が肥大化していないか？ → 構造を見直し

よくあるミスと対策

❌ if が10段以上続いて読解不能に

→ ✅ マップベースの制御に書き換える（オブジェクト or Map）

❌ switch 文で break を忘れて fall-through バグ発生

→ ✅ 各caseで必ずbreak or return する構造に

❌ UIのクラス切り替えで if を大量に書く

→ ✅ classNamesユーティリティやオブジェクト展開で解決

結語

条件分岐の最適化とは、**「どの構文を使うか」より「どう整理するか」である。
それは“分岐の責任とスコープを設計し、スケーラブルかつ可読性の高い制御構造を実現するための戦略”**である。

少ない分岐 → if / switch
多い分岐 or 関数の切り替え → オブジェクト or Map
分岐の意味を構造に持たせることで、責務が可視化される

JavaScriptにおける条件分岐最適化とは、
“条件の意図と責任を構造的に分離し、メンテナブルで明快な制御を構築する設計技術である。”