有限状態の状態遷移管理なんてしたくない！

http://d.hatena.ne.jp/kenmo/20050914#p1
より、有限状態機械の書き方が紹介されている。

私も高校1年の時にこのような書き方で行ってきたつもりだったが、私の場合この方法だといかんせん面倒だったのだ。
デメリットはもちろんのこととして
利点にデバッグしやすい（状態が明確）とかいているが実はというとデバッグしにくいなのだ。
状態が明確なのは良いと思う*1が、状態遷移の条件が複雑になればなるほど、そのプログラムを書いた本人がどの条件でどの状態に遷移するのかがわからなくなり、意外な条件の組み合わせで予想のつかない深みにはまる。という事があったからだ。状態遷移の条件を一まとめにしておくとか一つだけにしておくとかリストアップしておくとか頭の中で整理できれば良いが、普通は出来ない。時と場合とわがままによって条件が矛盾を起こしていくか起こしてしまう。

複雑な処理をするアプリケーションになればなるほどそれにはまりやすい。例えばWin32APIのウィンドウプロシージャを扱うプログラムなんてそうだ。はっきり言ってswitchの嵐は私は嫌いである。break抜けなんて諸悪のバグの根源である。

なので、機能単位でプログラムを組む状態数の少ないライブラリ製作の方が私には向いていた。というか、ライブラリ製作に逃げていた。（笑）

なので一時期ステート管理についてスマートな方法が何かどうか調べたことがあった。
そこで出てきたのが
google:FSMや
google:state map compilerや
http://d.hatena.ne.jp/studiokingyo/20040613#p1や
んー十万するGUIで状態遷移を管理するIDEの類であった。

一部にそれ関係の話題を扱ったサイトを私のアンテナに登録してあるので参照してみると良いかもしれない。

どれも私にとってパッとするものは無く、状態数の少ないプログラムばかり書いていた。
しかし、これから本格的なアプリケーションを製作するに当たってそんなことは言っていられない。
なんらかの方法を見つけ出さねばと考えた。結果、以下のアイディアが浮かんできたので記しておこうと思う

• 状態を対象にした正規表現みたいなBNFみたいな　それによって状態遷移エラーチェックや正常に状態遷移をしているかチェック（毎フレーム状態を保存する必要があるが・・・）
• やっぱり古典的？に、状態遷移条件を頭の中にまとめられるように努力する。例えば、有限状態機械がモジュール単位でバグなしで固まったらいじらない　や　状態遷移図をノートに取っておくとか　その為のオブジェクト指向か！？（笑）

続く・・・（ってか、最近書くことなすことまとまらずに続くことが多い　スマン）

*1:私は状態を明確にしておかないとプログラムを組めない性質