静的状態管理 〜第５回〜
今回で静的状態管理に関する連載（？）も最終回となりました。
静的状態管理についてまとめたいと思います。
静的状態管理の特徴・考え方
一連の処理の中で時間的にある一瞬を切り出して見たとき、その（時間的な）前後に頼ることなく、周囲の画面要素や変数などを見ることで、今はどのような状態であるべきかを判断します。
おおよその手順としては
- それぞれの処理対象要素に対して１つずつインスタンスを作って管理します。
例えば、電話番号の入力欄が３つに分かれていたとしても、その３つの入力欄が異なる状態をとることは考えられないので、１つのインスタンスで管理します。 - 対象要素に遷移する可能性のある“状態”をすべて挙げ、それらを定義します。
注目した要素に対して「そうなる可能性のある状態」をいくつでも定義しておきます。 - 対象要素の状態がどうあるべきかを判定するメソッドを実装します。このメソッドは、前項で定義した状態の中から判定します。
- イベントメソッドは、これらのインスタンスの状態の判定とその結果の適用を実装します。このとき判定と適用を行うインスタンスの順序に注意します。
これを行うことにより、状態の定義や判定とイベントや時間的前後関係が（論理的に）切り離され、状態管理の汎用性が増します。
静的状態管理の利点
利点として以下の事柄が期待できます。
※イベントメソッドの中に細かい単位で判定と適用をゴリゴリ記述した場合との比較です。
- 〔バグの減少〕「同じ状態にならなければならないときでもイベントの順序が違えば同じ状態にならない」というバグは、静的状態管理では発生しません。
- 〔デバッグが楽〕デバッグが非常に楽で、判定結果を確認したり、任意の“状態”に遷移させたりすることができます。
- 〔分担作業可〕イベントの内容が決定する前に、ある程度の作りこみ（状態定義や状態判定）が可能です。
- 〔呼び出しも簡単〕イベントメソッドの実装が非常に楽です。各イベントでは、どのインスタンスをどんな順番で判定＆適用するかを考えればよいのです。
- 〔拡張性・保守性〕どこでどんな処理をしているかがわかりやすいので、改造・保守などが楽になります。また、改造時の考慮漏れなどが減ります。
静的状態管理の欠点
当然、静的状態管理には欠点もあります。
- 〔動的な場合〕時間的な前後関係に依存して状態が決定される場合、静的状態管理は使えません。（無理に使ってもいいことありません。）
- 〔記述量〕ソースコードの記述量がやや増えると思われます。（オブジェクト指向にして状態と時間を切り離した代償です。）
- 〔オブジェクト〕オブジェクト生成数が増えます。（単なる関数をどんどん呼び出すだけではなく、オブジェクトを作成してとっておくためです。）
- 〔少量には不向き〕少量の画面要素の管理には向きません。かかった手間に対して、大きな効果は得られません。
静的状態管理の適性
状態を静的に管理できるかどうかは、
- 静的に状態を定義可能
- 例：入力欄Ａは、「活性（入力可能）」「非活性（入力不可）」「非表示（入力不可）」の３つの状態が存在する。
- 静的に状態を判定可能
- 例：入力欄Ａは、入力欄Ｍが空欄ではないときは「活性」、入力欄Ｍが空欄で変数pが3以上のときは「非活性」、それ以外のときは「非表示」となる。判定の前後の処理や判定のタイミングに、判定結果は依存しない。
- 判定の依存方向が一定
- 例：入力欄Ａは、入力欄Ｍと変数pに依存しているが、これとは逆に、入力欄Ｍや変数pは（間接的にも）入力欄Ａに依存することはない。
具体的には、
- ウェブアプリケーションの画面
- データの入力画面
- 申し込み・登録画面
また、
- ゲームの画面
- 問題・クイズの画面
- ランダムな処理をする画面
- ほとんど状態変化する部分がない画面
サンプルクラスに関して
静的状態管理のサンプルとして第２回でクラスの例を出しました。
このクラスもサンプル用のシンプルな機能になっていますのでご注意ください。
あくまで、考え方を理解していただくために用意したものであり、状況により最適なクラスを考え、作って使うのが望ましいと思います。
おわりに
「静的状態管理」について連載しましたが、「静的」ではない状態管理もあるのでしょうか？
→それについてはまた日を改めて意見を述べたいと思います。
ご静聴ありがとうございました。*1
*1:ここはあんまり見てる人も少ないですから、貴重ですぞっ！ …きっと。
