振る舞いは「判断の結果」であり、書くものではない

ここまでで、 判断は 人がその場で行うもの ではなく、 構造として先に固定されるべきもの だ、という話をしてきました。

では、構造に固定された判断は、 最終的にどこへ行き着くのでしょうか。

それが 振る舞い（behavior） です。

振る舞いは「考える」ものではない

設計が弱いコードでは、 振る舞いは次のように書かれます。

  • if / when で分岐する
  • 状態を見て都度判断する
  • 条件が増えるたびに分岐が増える

このとき、プログラムは常に 「今、どう動くべきか？」 を 実行時に考え続けている 状態になります。

これは一見、自然に見えます。 しかし設計として見ると、これは負けています。

なぜなら、

  • 振る舞いの正しさが
  • 毎回の判断に依存している

からです。

良い設計では、振る舞いは「選ばれている」

設計されたコードでは、 振る舞いは 書かれるもの ではありません。

すでに選ばれている のです。

  • ある状態になった時点で
  • どの振る舞いが可能かは決まっている
  • それ以外の振る舞いは、そもそも存在しない

つまり、

「どう動くか」を考える必要がない

状態が確定した瞬間に、 実行できる振る舞いも一意に確定する これが設計された状態です。

振る舞いを制御するのは「構造」

ここで重要なのは、 振る舞いを縛っているのが、

  • if 文
  • フラグ
  • コメント
  • 運用ルール

ではない、という点です。

縛っているのは 構造 です。

  • 型によって呼べる関数が決まる
  • 状態オブジェクトによって持てる操作が決まる
  • API によって渡せる情報が制限される

このとき、 振る舞いは構造の結果として現れるだけ になります。

「書けない振る舞い」を作る

設計のゴールは、 正しい振る舞いを書くことではありません。

間違った振る舞いを書けなくすること です。

  • そのメソッドは呼べない
  • その状態ではその操作は存在しない
  • その値は生成できない

こうした制約が積み重なると、 実装者は「正しいコードしか書けない」状態になります。

ここに至って初めて、

  • 気をつける
  • レビューで弾く
  • テストで守る

といった 人の判断 が、脇役になります。

振る舞いが増えたら、設計を疑う

もし振る舞いが増え続けているなら、 それは仕様が複雑なのではなく、

判断が構造に押し込まれていない 可能性が高いです。

  • 状態が曖昧
  • 責務が混ざっている
  • 境界が引かれていない

その結果、 振る舞いがコード上で増殖します。

振る舞いが増えたら、 「どう実装するか」ではなく、 どの判断が構造化されていないか を見直すべきです。

この章のまとめ

  • 振る舞いは、判断の結果である
  • 判断は、実行時に行うものではない
  • 判断は構造に固定される
  • 構造が、可能な振る舞いを決める
  • 良い設計とは、間違った振る舞いを書けない状態である

次の章では、 この「構造による制約」が 境界設計・責務分離とどう結びつくか を扱います。