FSMとしてプログラム全体を構築するのに適したデザイン？

Question

ここのようなFSM/プッシュダウンオートマトンアプローチを使用してパーサーを構築しました（そして、それはうまく機能します！）： C ++ FSMの設計と所有権これにより、優雅に終了し、パーサーステージで何か問題が発生したときに役立つエラーメッセージをユーザーに出力できます。

私は私のプログラムの残りの部分でそれを成し遂げる良い方法について疑問に思っていました、そして、当然、パーサーのアプローチが私の心に飛び出しました...

すべてのオブジェクトを状態にします。これには、実行の段階に応じてオブジェクト固有の関数を呼び出すスイッチステートメントがある単一のイベント（）関数があります。オブジェクト固有の列挙でそれを追跡し、コードをより読みやすく保つことができます（case parser より読みやすい case 5）。これにより、私が作成した州のプッシュダウンツリーを閉じることができます（ m_parent* 私の他の質問でアプローチ）。

これは良いデザインですか（FSMモードですべてを強制します）？より良い方法はありますか、そしてそれはどれほど複雑になりますか（FSMは実装とテストが非常に簡単だと思います）？

提案をありがとう！

PS：ブーストには必要なものがすべてあることを知っていますが、特にブーストで外部依存関係を制限したいと思います。 C ++ 0xは大丈夫です（しかし、ここでは本当に関連していません）

Answer 1

あなたがしていることは、プログラムに（シンプルな）仮想マシンを構築するようなものです。 FSMは、レクシングや解析などのいくつかの制限された問題に適している傾向があります。おそらく注目に値するように、「無料で」ロギングとエラー管理をかなり手に入れることができます。

ただし、FSMパターンをすべてに適用しようとすると（通常、明示的な状態にしたくない非常に多くの状態を含むGUIプログラムなど）、あなたはそれに気付くでしょう。施設も必要です デバッグ あなたのFSM（C ++デバッガーはあなたの州やイベントを理解しないため）と施設 リンクと再利用 州（州はOOレベルの構成ではないため）。コードを他の誰かに引き渡したい場合は、FSMを正常に使用するために追加のトレーニングが必要になります。複数のアプリケーション用にFSMエンジンを1つ保持したいと思いますか？もしそうなら、バージョンとアップグレードにどのように対処しますか？

適切なジョブに適切なツールを使用してください。すべてのアプローチには長所と短所があります。ソリューションは別のレイヤーを追加します 複雑: ：より多くのC ++ -ISHの方法でのロギングとエラー処理に対処できます。 C ++コードの作成に満足していない場合は、FSM言語を構築するのではなく、他の既存の言語を検討する場合があります。

Answer 2

ほとんどの人は、スイッチ/ケース/デフォルトの代わりに継承を使用します。しかし、すべてを一つの方法に強制するという考えは本質的に間違っています。常に必要な各機能に、それ自体のメリットにアプローチする必要があります。

Answer 3

いつでも見ることができます ブースト.