フラグを使った状態管理をやってはいけない理由

以下のような is〇〇というフラグが多く設定されたデータを見たことはないだろうか。

■TypeScriptの型定義

type Order = {
  id: string
  price: number
  isPurchased: boolean
  isShipped: boolean
  isDelivered: boolean
  isCancelled: boolean
}

■データベースの設計

order_id	product_name	price	is_purchased	is_shipped	is_delivered	is_cancelled
1	マグカップ	2000	T	F	F	F
2	ノート	500	F	T	F	F
3	本	1800	F	F	T	T

直感的で実装も簡単に見える。

しかしこのアプローチは、システムの複雑性と脆弱性をただただ高める行為のため、やってはいけない。

今回はその理由を解説する。

フラグが生む「ありえない状態」ありえない状態を許すと何が起きるか 1. 防衛的なコードを書き続けなければならない 2. 「ありえない」と「エッジケース」の区別がつかない 3. 正しく実装しても破綻しうるまとめ

フラグが生む「ありえない状態」

4つのフラグがあれば、論理的な組み合わせは 2⁴ = 16通りになる。

しかし現実の注文フローで意味を持つのは、たとえば次のような数パターンだけだ。

isPurchased	isShipped	isDelivered	isCancelled	意味
true	false	false	false	購入済み・未発送
true	true	false	false	発送済み・未配達
true	true	true	false	配達完了
false	false	false	true	キャンセル済み

残り12通りは「ありえない状態」だ。

isDelivered=true(発送済み) かつ isPurchased=false(購入前) のような状態は、現実のビジネスロジックでは存在しえない。
しかし、 is〇〇のようなフラグを多用したデータ構造は、それを禁止することができない。

この「ありえない状態を表現できてしまう」という事実が、あらゆる問題の根源となる。

ありえない状態を許すと何が起きるか

1. 防衛的なコードを書き続けなければならない

ありえない状態を表現できるということは、それに対処するコードを書かなければならないということだ。

function processOrder(order: Order) {
  if (order.isDelivered && order.isCancelled) {
    throw new Error("配達済みかつキャンセル済みの注文は存在しない")
  }
  if (order.isShipped && !order.isPurchased) {
    throw new Error("購入前に発送はできない")
  }
  if (order.isDelivered && !order.isShipped) {
    throw new Error("発送前に配達はできない")
  }
  // ... 他にも無数のガード節
}

この防衛的なコードを書くためには、まず「ありえない組み合わせを全パターン想像する」必要がある。
これは認知コストが高い。
現実にありえないケースを正確に列挙するのは難しく、抜け漏れが生じやすい。

テストケースも同様である。
フラグが1つ増えるたびに組み合わせは倍増し、テストケースも比例して膨張する。
しかしこれを省略すれば致命的なバグにつながるため、省略することもできない。

2. 「ありえない」と「エッジケース」の区別がつかない

ガード節が増えると、次の問題が生じる。

「このガード節は現実にはありえないケースへの対処か、それとも実際に起きうるエッジケースへの対処か」が、
コードを読んだだけではわからなくなる。

// 発送済みかつキャンセル済み
if (order.isShipped && order.isCancelled) {
  // 仕様として商品発送後のキャンセルを許容しているのか？それともこれはありえないケースなのか？分からない
  handleShippedButCancelled(order)
}