概要
条件分岐はコード内で最も多く使われる制御構造だが、
乱用すると分岐がスパゲッティ化し、ロジックが不透明化する。
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における条件分岐最適化とは、
“条件の意図と責任を構造的に分離し、メンテナブルで明快な制御を構築する設計技術である。”