静的状態管理 〜第１回〜
効果があるのは
効果があるのは次のような画面管理です。- 動的に変化する項目が多い
- 静的に状態を定義できる
“静的に状態を定義できる”とは、
「入力項目Ａの値が1で、プルダウンＢが3ではないとき、入力項目Ｃは非活性」
というように、時間的なある一瞬を切り出して画面や内部で持っているパラメーターの値を見たとき、
それぞれの項目（または複数の項目をまとめた画面部分）について、その状態を定義できることを言います。
それとは逆に、
「ボタンＸ→ボタンＹの順で押したら入力欄Ｚは活性で表示，Ｙ→Ｘの順でＺは非活性で表示」
などと、状態が時間や順序に影響されるものは、ここでは“静的”としていません。
考え方（イベント）
イベントを実装するときは、「そのイベントで何をするか」ではなく、
「そのイベントでどこを変えるか」を考えて実装します。
→「どう変えるか」はイベントの実装では考えません！！
◇たとえ話
※社長が・・・
社長 →管理職「おい、Ａの担当者はだれかね？」
管理職→社長 「こいつです」
社長 →Ａ担当「いま、Ａの部分はどうあるべきかね？」
Ａ担当→社長 「Ａは“○×△”であるべきです」
社長 →Ａ担当「ではそれにしたまえ」◇擬似コード（実装の一例）
※ログイン画面でゲストのチェックボックスをクリックしたとき・・・
function ゲストにチェック() {
var 担当オブジェクト = マネージャー.担当取得(パスワード入力欄に対応するキー文字列);
var パスワード入力欄のあるべき状態 = 担当オブジェクト.あるべき状態の判定();
担当オブジェクト.状態変更(パスワード入力欄のあるべき状態);
}１箇所を変更するのに３行コードを記述します。
「どこを変えるか」を考えたとき、この３行の組を変える箇所のぶんだけ記述します。
「どうあるべきか」や「どう変えるか」は“担当者”にまかせてしまうのです。
考え方（状態定義）
細かいことを任せられた“担当者”についても実装が必要です。- まず最初に“状態”を考えます。
- 次に“状態”の判定方法を考えます。
◇たとえ話
※テーマパークのとあるアトラクションＢで・・・
管理者→Ｂ担当「じゃあ、キミはこれからＢの担当ね」
Ｂ担当→管理者「Ｂってどうなるんですか？」
管理者→Ｂ担当「Ｂには“停止”と“公開”と“試運転”のときがあるんだよ」
Ｂ担当→管理者「それぞれ、どんなときに？」
管理者→Ｂ担当「営業時間中は“公開”，営業開始の前１時間は“試運転”，それ以外は“停止”だね」◇擬似コード（実装の一例）
var 担当オブジェクト = マネージャー.担当作成(パスワード入力欄に対するキー文字列);
担当オブジェクト.状態定義(状態名「非表示」, 状態「非表示」に変化させる関数);
担当オブジェクト.状態定義(状態名「非活性」, 状態「非活性」に変化させる関数);
担当オブジェクト.状態定義(状態名「編集可」, 状態「編集可」に変化させる関数);
担当オブジェクト.状態判定 = function() {
// あるべき状態を定義済みの状態名の中から判定して返す。
return 定義済みの状態名のどれか;
};このようにコーディングすると、オブジェクトが対応する“とある部分”について、
「（周囲の状況が）どのようなときに、（その部分が）どうであるべきか」
を考えることになり、静的に状態を考えていることになります。
メリット
通常は- 状態定義
- 状態判定関数
- イベントからの呼び出し
の順で実装します。
『手続き型』ではイベント実装時に「どの項目を」「どのように」変化させるかを考えましたが、
ここでは状態定義と状態判定関数の実装時に「どのように」を、イベント実装時に「どの項目を」を考えます。
考える箇所（記述する場所）を分離することで、漏れや間違いを減少させ、またわかりやすいコーディングとなります。
また、『手続き型』では１つのイベントに注目して考えますが、ここでは１つの画面部分に注目して考えているので、たいていの場合は考えやすくなります。
次回予告
じゃあ、JavaScriptでどうやるの？という部分について解説したいと思います。
