設計の話をしていると、 「状態」という言葉が、 とても曖昧に使われがちです。
- 画面の表示状態
- 一時的な入力値
- データベースの中身
これらはすべて「状態」と呼ばれます。
しかし本書では、 もう一段、踏み込んで定義します。
状態とは何か
本書における状態とは、
判断の結果を、構造として保持したもの
です。
言い換えると、
- 状態は、判断そのものではない
- 状態は、判断が終わった「あと」の姿
です。
「今、何ができるのか」 「次に何をしてよいのか」
それらはすべて、 状態が表現しています。
状態は、判断を繰り返させないための装置
判断が構造で表現されていない設計では、
- 毎回 if で確認する
- 毎回 null チェックをする
- 毎回条件を思い出す
ということが起きます。
これは、 同じ判断を何度も繰り返している 状態です。
良い設計では、
- 一度判断したら
- その結果を状態として持ち
- 以降は状態を見るだけ
になります。
状態とは、 判断を 保存するための構造 です。
状態が嘘をつくと、設計は壊れる
状態が正しく設計されていないと、 次のようなコードが生まれます。
- 本当は使えないのに、使えてしまう
- 本当は準備中なのに、完了に見える
- 条件次第で意味が変わるフラグ
これはすべて、
状態が、判断結果を正しく表現できていない 状態です。
状態が嘘をつくと、 判断が再び人に戻ってきます。
「ありえない状態」を表現できてはいけない
良い状態設計では、
- ありえない組み合わせ
- 矛盾した状態
- 中途半端な段階
を、そもそも表現できません。
たとえば、
- Loading と Ready が同時に true
- 取得エラーなのにデータが存在する
- 未初期化なのに操作できる
こうした状態を、 型や構造で排除します。
これは、 「注意する」話ではありません。
表現 (実装) できないようにする という設計の話です。
状態は、判断が終わった世界を表す
第6章で、 境界の話をしました。
状態は、 その境界の 内側 にあります。
つまり、
- 状態を見るコードは
- もう判断をしなくてよい
世界です。
状態が正しく設計されていれば、
- 「この状態なら、これをしてよい」
- 「この状態なら、迷わなくてよい」
という前提が、 構造として保証されます。
この章のまとめ
- 状態とは、判断の結果である
- 状態は、判断を繰り返させないための構造である
- 状態が嘘をつくと、判断が人に戻る
- 良い設計では、ありえない状態を表現できない
次の章では、 この「判断」が いつ起きるのか。
つまり、 判断が発生する「瞬間」について、 イベントという切り口から見ていきます。