makotan _at_ gmail dot com

情報と状態の流れとデータの持ち方

どんな風にデータを持つか?どう変化させるか?っていう話
情報に状態を持たせるときに状態をフラグ一つ一つに割り当てて持つとほぼ意味がないので違う持ち方をするのがポイント
まず、状態はそれぞれ固有の「値」に割り当てる。
状態名とかの文字列とかenumとかに割り当てると後からいろいろ楽
集計とか検索の時にも状態名とかの文字列で状態を把握できる
この情報の状態は基本的には情報と一緒にみれるようにするのが実装上は楽


状態を変化させるとき
Aって状態からBって状態に変更するとき、データを直接Bに更新する方法と、Aの次の状態に進める方法の二つがある。
一瞬にてると思われるこの二つの方法はかなり大きな違いがある


直接Bに更新する方法は
遷移元の機能が遷移先の状態を知ることになるので、状態の追加・修正・削除に弱くなるのが欠点
ほとんどのアプリの作り方はこれ


次の状態に進める方法は
遷移元の機能は遷移先の状態を知る必要がないので、状態の追加・修正・削除に強いのが特徴
ただし、状態の遷移を管理するものを作る必要がある。
この場合でもデータ移行用に状態に直接変更する機能があった方が良い
で、この方法がおすすめというかこの方法が基本。
追加として、想定される今の状態を渡すと遷移元が食い違っている(大抵は既に状態遷移済み)もチェックできる


複数の状態があるときの作り方
ごくまれに複数の状態を管理する必要があるばあいもあって、このときの作り方は

  • 情報と状態を管理するテーブルを分ける。
  • 状態を管理するテーブルには有効・無効の日付を持たせる
  • 状態が有効なものが複数を許可する

基本的にはこれだけなんだけど・・・さらにややこしい制御する必要がある場合には

  • 状態を管理するテーブルに上位の状態を保存する

ってことをやる。上位の状態さえ保存すれば自由自在な制御が可能になるはず


状態の履歴管理を追加する方法
状態の追加・変更の時に元の状態と次の状態を誰がいつ実行したのかを記録する
これで必要最小限の履歴管理ができるようになる



これ、ぶりの実装説明のような気がする・・・これ考えたの5年位前か〜懐かしいなぁ〜