2009-05-12 4 views
1

私は、ブール条件から完全に構成された所定のフローチャートと、応答として実行される一連の論理を持っています。フローチャートのモデリング

フローはあまり変わらない可能性がありますが、その可能性は低いです。 (新しいステップが導入されるか、条件の順序が変更される可能性があります)

これをコードする最良の方法は何でしょうか?入れ子にされたif文の大きなセット?ワークフロー基盤?他に何か?

答えて

3

柔軟性が第一の関心事でない場合は、全体のフローチャートロジック全体をハードコードするだけです。最も単純なものが最も良い場合があります。オリジナルのフローチャートの概念に従ってコードを構造化してください。そうすれば、類推を見て将来必要に応じて変更するのは簡単になります。

Windows Workflow Foundationは、既に慣れ親しんだり、習得したいと思っている人にとっては良いツールです。

+0

Re; WWF;私は学習曲線を気にしません、私はそれが過剰な(アーキテクチャとパフォーマンスが賢明かもしれません) –

3

変更の可能性があることが確認されたフローチャートは、実装のためにステートマシンを招待します。 Stateパターンまで進んだり、単純にステートマシンを実装するか(説明したケースでは、データ駆動型は正当化されていないようですが)、実装の詳細です。

+0

それは私が最初に考えたことだが、それから私は状態パターンの内部状態オブジェクトは、一方の状態から他方の状態に至る操作は、コンテナオブジェクトによって通常は2倍になりますが、私の場合は唯一の共通のインターフェースはほとんどブール条件です。 ここで州がどのくらいうまく機能しているかわからないので、 –

+0

州機械の提案。マシンの各状態は、フローチャートのグラフのノードになります。 –

関連する問題