問題タブ [state-pattern]

各状態がイベントキューから取得したイベントを処理する状態パターンの実装があります。したがって、基本Stateクラスには純粋仮想メソッドがありvoid handleEvent(const Event*)ます。イベントは基本クラスを継承Eventしますが、各イベントには、異なるタイプ（int、stringなど）のデータが含まれています。イベントデータを抽出するにhandleEventは、受信したイベントのランタイムタイプを判別してから、ダウンキャストを実行する必要があります。イベントは動的に作成され、キューに保存されます（したがって、アップキャストはここで行われます...）。

ダウンキャストは悪い設計の兆候であることを私は知っていますが、この場合それを回避することは可能ですか？基本クラスのStateに各イベントの仮想ハンドラーが含まれるVisitorPatternを考えていますが、イベントをキューからデキューして現在の状態に渡すコードでダウンキャストを実行する必要があります。（少なくともこの場合、大きなswitch(eventID)ものは1か所だけになります...）。ビジターパターンは、ダウンキャストを回避するための最良の方法（ベストプラクティス）ですか？

これが擬似コードです（boost::shared_ptrこの例ではパスしていますが、とにかくダウンキャストが発生します）：

時々、オブジェクトの状態をサポートする必要があります。私が理解しているように、2つのアプローチがあります。

1. ENUM（シンプル）
2. STATEパターン（OC原則）

そのような目的のためにStateパターンを使用する必要があることは明らかです（私にはわかりません）。

しかし、私がしばしば直面する他のコードを読むと、状態パターンだけでなく列挙型に直面します。状態パターンには力がありますか？

現在構築中の請求システムの状態ベースの機能に頭を悩ませています。このシステムは、請求書の計算、手動承認、印刷、およびアーカイブをサポートします。

最初は、State パターンを使用してこれをモデル化する必要があると考えました。請求書は、印刷、アーカイブなどを現在割り当てられている状態に委任するコンテキストになります。

しかし、異なる状態 (作成済み、承認済み、印刷済み、アーカイブ済み) が同じ操作をサポートするべきではないため、これは明らかに悪い考えです。たとえば、以前に承認されたことのない請求書を印刷することはできません。サポートされていない操作に対して例外をスローすると、LSP に違反します。この問題の一般的な説明はこちらで見つかりました。

これを適切に実装する方法を知っている人はいますか?

PS: これはつまらない宿題のように聞こえるかもしれませんが、そうではありません。実世界のシステムにはこれが必要です。

これが他の場所で答えられた場合はお詫びします。これを行うための最良の方法を自分に納得させるのに十分な情報を見つけることができませんでした。また、これはコードのない長い説明であることも理解していますが、私が行っていることを示すためにサンプルコードを作成する必要があるかどうかを教えてください。

基本的に：

• System.in/outを使用してJavaで通信プロトコルを実装する
• 現在のアプローチは、スキャナーがコンテキストクラスのSystem.inでインスタンス化される状態パターンを実装しています。
• 具体的な状態は、コンテキストメソッドを呼び出してスキャナーから読み取り、その後、スキャナーから返された値に基づいてアクション/遷移状態を適切に実行します。

状態パターンを使用する私の当初の意図は、System.inからこのようなシーケンスを解析するときにコードを単純化することでした（構文については聞かないでください。これは私が使用する必要があるものです）。

• コマンド名=X
• ヘッダ
• ヘッダー情報の行
• コンテンツ
• コマンドの内容の行
• ENDCONTENTS
• エンドコマンド

私は通常、受け取ると予想されるコマンドのタイプごとに具体的な状態を定義します。上記のシーケンスを例として使用すると、{WAITING_FOR_COMMAND、COMMAND_RECEIVED、PARSING_HEADER、PARSING_CONTENTS、PARSING_DONE、COMMAND_PROCESSED}のような状態セットが作成されます。最初はWAITING_FOR_COMMANDにいて、「COMMAND NAME = X」を受信するとCOMMAND_RECEIVEDに移行し、「HEADER」が入ったらPARSING_HEADERなどに移行します。この設計では、すべてのエッジケースをトラバースします。プロトコルが簡単になり、プロトコルが微調整されたときのコードの更新/保守も簡単になります。明らかに、大規模なswitchステートメントや反復的な境界チェックよりもはるかに優れています。

私が抱えている問題は、具体的な状態の動作を具体化するにつれて、コンテキストクラスでますます多くの状態変数を宣言していることに気付くということです。これは、非常に公開されたインターフェイスと、コンテキストと具体的な状態クラス。このプロトコルのコマンドシーケンスは任意の長さにすることができ、コマンドシーケンスが完了するまで、コマンドシーケンスの各項目によって与えられた情報を保存する必要があります。

上記のコマンドシーケンスを例にとると、「COMMAND ID = X」の後に、「ENDCOMMAND」を受け取ってコマンドを完全に処理した後、後で使用できるように値Xを保存します。「HEADER」の後に、実際にコマンドを処理するときに「ENDCOMMAND」を受け取った後、将来使用するためにヘッダー情報を保存したいと思います。などなど。コンテキストクラスにcommandIdとヘッダー状態変数を追加するだけで今のところは機能しますが、私にはまったくきれいに見えないか、うまくカプセル化されていないようです。

誰かがこの問題にどのように取り組むかについての高レベルの提案がありますか？このための状態デザインパターンのより良い使用法はありますか？

私が遊んでいるいくつかのアイデアに注意してください：

• 各タイプのコマンドシーケンスの状態コンテキストを定義し、System.inから関連するコマンドを受け取ったときに適切なコンテキストを呼び出します。これは巨大なスイッチブロックを持っているのとほぼ同じくらい厄介なようで、デザインを過度に複雑にしているようです
• 複合FSMをサポートする本格的なFSMアーキテクチャを設計します。このアーキテクチャでは、各コマンドシーケンスが包括的なFSM内で独自のFSMを占有します。これは私にはやり過ぎのようです
• コマンドシーケンスタイプごとにさまざまなサブクラスを持つProtocolCommandオブジェクトを作成します。移行時にこれらを各状態に渡し、進行するにつれて徐々に構築することができます...しかし、これにより状態インターフェイスが乱雑になり、すべての状態に、必ずしも使用しないパラメータを取り込むように強制されます

本当にありがとう！申し訳ありませんが、これは非常に冗長でした。何か明確にできるかどうか教えてください。

次の問題があります: GWT を使用してプロセスをモデル化しようとしています。ここでは、いくつかの送信ボタンを備えたビューがいくつかあります。そして、ボタン 1 を押すとサーバーとの対話が作成され、すべて問題がなければ、次のビューが読み込まれます。私の問題は、本当に厄介なスパゲッティコードを取得することです（私が何を意味するかを示すために非常に高レベルです）：

ある種の抽象化などを作成する方法はありますか? 多分状態パターン？どのように？どうもありがとう！

私はまだ循環参照の危険性を理解しようとしています。まれな場合にのみ使用する必要があるとよく読みます。ただし、正規の状態パターンでは、「状態」オブジェクトは遷移を引き起こすために「コンテキスト」オブジェクトを参照する必要があり、「コンテキスト」オブジェクトはその動作をトリガーするために「状態」オブジェクトを参照する必要があります。

これは循環参照ではありませんか？そうでない場合、循環参照とどのように関係していますか? もしそうなら、なぜこれが受け入れられるのですか？

http://en.wikipedia.org/wiki/State_pattern

http://source Making.com/design_patterns/state

LAN 経由で POS (Point of sale) 端末を制御するために使用される DLL を開発しています。

DLL は、次のような操作を実行するコマンドを提供します。

• ログオン
• ログオフ
• 認可
• カードデータの読み取り
• キャンセル
• 返金
• ネットワーク診断

また、DLL は Connect() および Disconnect() 関数を提供します。

POS 端末はさまざまな状態になる可能性があるため、State パターンは DLL で使用される可能性があると考えています。

擬似コード:

PosLoggedonとPosLoggedoffはどちらも有効と考えることができる 2 つの状態ですが、他の状態を判断する方法がわかりません。

PosAuthorisation、PosReadCardDataなどの状態を作成して、POS 関数に対応させることは理にかなっていますか? たぶん意味不明…

「進行中の現在のコマンド」と「現在の POS 状態」が混在しているため、状態パターンを正しく使用する方法について混乱しています。

おそらく、PosCommandInProgressのような状態が必要ですか?

アドバイスをいただければ幸いです。

どうもありがとう。

操作の現在の状態を設定できるように、Enum STATE パターンを作成しようとしています。C＃（私は思う）では、このパターンを使用しました：

AndroidでEnumを使用すべきではない、または使用できないことをどこかで読みました。Android でこのデザイン パターンを複製するにはどうすればよいですか?

私の TCP アプリケーションでは、IO がブロックされている限り、ステート デザイン パターンが役立つように見えました。

私の SwingWorker の doInBackground() は、1 つのオブジェクトへの参照によって、TCP 接続の状態の読み取り、書き込み、受け入れをループする可能性があります。ウィキペディアのトーク ページの例を参照してください: http://en.wikipedia.org/wiki/Talk%3AState_pattern。

しかし、サーバーをノンブロッキング IO にリファクタリングしたところ、役に立たなくなりました。Select() は IO の準備ができているチャネルのグループを返し、これらは一連の if ステートメントで SelectionKey 状態を参照することによって処理されました。

IO が非ブロッキングの場合に State Design Pattern がまだ有用であるかどうかを、経験または理解から確認できる人はいますか?

Stateの設計パターンとTCPの関係を正しく把握できているか不安なので質問します。

いくつかの状態を遷移するゲームを設計しているときに、2つのパターンが使用されているのを確認しました。1つは次のとおりです。

1）列挙型パターン。

2）抽象があり、抽象を拡張して各状態を表すサブクラスがあるクラスの状態パターン..単一状態パターン？

どちらも良い解決策のように見えますが、ゲームにとってよりクリーンで理解しやすいものは何でしょうか？

個人的にはモノステートが好きですが、列挙型の方法が道のようです。