第3章では、 判断を人に持たせるのではなく、 構造で表現する ことが設計だと述べました。

では、その判断は、 構造の中で どんな形 を取るのでしょうか。

その答えが、 状態 です。

状態とは、「今、何が許されているか」である

本書で言う状態とは、

  • 変数の値
  • フラグの on / off
  • データの有無

といった、 表面的な話ではありません。

状態とは、

「今、このコードは何をしてよくて、何をしてはいけないか」 を表すものです。

たとえば、

  • 今はまだ送信してはいけない
  • もう変更してはいけない
  • ここから先は読み取り専用である
  • この操作は一度しか許されない

こうした判断が、 暗黙の了解ではなく、 コードとして表現されているかどうか

それが、 状態設計の良し悪しを分けます。

判断は、必ず状態に依存する

第3章で扱った判断は、 必ず何かに依存していました。

  • この順番で呼んでよいのか
  • 今、この処理をしてよいのか
  • この値を変更してよいのか

これらはすべて、

「今がどんな状態か」 によって決まります。

つまり、

  • 判断を構造で表現する
  • 状態を構造で表現する

この二つは、 実は 同じ話を違う角度から見ている だけです。

状態が曖昧だと、判断が漏れ出す

状態がはっきり定義されていないコードでは、 判断が漏れ出します。

  • null かもしれない
  • 呼ばれる順番は暗黙
  • 途中の状態が存在するかどうかわからない

このときコードは、

  • if を増やして守る
  • コメントで注意書きをする
  • テストで網を張る

という方向に進みます。

しかしそれは、

状態を構造で表現できていない という問題の結果にすぎません。

良い状態設計は、「ありえない状況」を消す

良い状態設計の目的は、 状態を増やすことではありません。

ありえない状態を、表現できなくすること です。

  • まだ準備できていないのに実行できる
  • 完了しているのに再実行できる
  • 必須の値がないのに処理が進められる

こうした状況を、

  • if で防ぐ のではなく
  • 構造として存在しない

ようにします。

その結果、 判断は自然と減っていきます。

状態を構造で表現する、ということ

状態を構造で表現するとは、

  • 状態ごとにできる操作を限定する
  • 状態が変わるタイミングを限定する
  • 状態の組み合わせを制限する

ということです。

これは、

  • 「ちゃんと使えば大丈夫」 ではなく
  • 「間違って使えない」

という設計を意味します。

状態が構造に落ちていれば、 判断はそこから外に出てきません。

状態を構造で表現できていないコードの兆候

次のようなコードは、 状態設計が弱い可能性があります。

  • Boolean フラグが増え続ける
  • null チェックがあちこちにある
  • 「この場合だけ特別」が多い
  • 呼び出し順をコメントで説明している

これらはすべて、

状態を、人が握っている サインです。

状態設計は、設計の中核である

判断を構造で表現する。 その最も強力な手段が、 状態設計です。

  • 判断が減り
  • if が減り
  • 読むときに考えることが減る

それは、 コードが単純になったからではありません。

判断を、状態として引き受けたから です。

この章のまとめ

  • 判断は、必ず状態に依存する
  • 状態が曖昧だと、判断がコードの外に漏れ出す
  • 良い設計は、状態を構造で表現する
  • 状態設計は、判断を減らすための設計である

次の章では、 この「状態」を、

  • 型
  • API
  • オブジェクト
  • ライフサイクル

といった、 具体的な構造 に どう落とし込んでいくかを見ていきます。