問題タブ [state-pattern]

最近、休止後にC ++開発に戻り、StateDesignPatternの実装について質問があります。GoFの本とまったく同じように、バニラパターンを使用しています。

私の問題は、ステートマシン自体が組み込みシステムの一部として使用されるハードウェアに基づいているため、設計が修正されて変更できないことです。これにより、2つの状態（特に）の間に循環依存が発生し、これを解決しようとしています。簡略化されたコードは次のとおりです（通常どおりヘッダーを使用してこれを解決しようとしましたが、それでも問題が発生しました。このコードスニペットではヘッダーを省略しています）。

問題は、基本的に、状態パターンでは、次の状態のコンストラクターを呼び出すContextクラスのChangeStateメソッドを呼び出すことによって状態遷移が行われることです。

循環依存のため、「問題」状態の両方のコンストラクターを事前に定義することができないため、コンストラクターを呼び出すことができません。

私はこの記事を見て、理想的な解決策のように思われたテンプレートメソッドを調べましたが、コンパイルされず、テンプレートに関する私の知識はかなり限られています...

私が持っていたもう1つのアイデアは、多重継承を介してヘルパークラスをサブクラス化された状態に導入し、基本クラスのコンストラクターを指定して、状態サブクラスのコンストラクターを参照できるかどうかを確認することです。しかし、それはかなり野心的だったと思います...

最後に、ファクトリメソッドデザインパターンを直接実装することが、問題全体を解決するための最良の方法でしょうか？

State パターンを使用して、単純な有限状態マシンを実装しました。ウィキペディアで提供されている説明、具体的には推奨される Java 実装を見て、Stateインターフェイス (つまり、さまざまな状態) を実装するクラスがシングルトンではないのはなぜだろうか?

推奨される実装では、遷移が発生するたびに新しい状態が作成されます。ただし、各状態を表すには 1 つのオブジェクトで十分です。では、遷移が発生するたびに新しいインスタンスを作成して時間を無駄にするのはなぜでしょうか?

まず、状態オブジェクトにインスタンス変数がない場合に状態オブジェクトを共有する方法を誰か説明できますか?

このテキストは、GOF の 308 ページ、項目 3 (結果セクション) からの抜粋です。

状態オブジェクトは共有できます。状態オブジェクトにインスタンス variabkes がない場合、つまり、状態オブジェクトが表す状態がその型に完全にエンコードされている場合、コンテキストは状態オブジェクトを共有できます。状態がこのように共有される場合、それらは本質的にフライウェイトです。

このテキストを説明できる人はいますか?

第二に、状態遷移の決定へのアプローチは何ですか? 次のどの状態を伝播するかの決定を意味しますか?

助けてください。ありがとう。

状態パターンについて読んだことがありますが、それを実装する Swing アプリケーション (例: 電卓) を調べて知識を深めようとしています。

そのようなチュートリアルはどこにありますか?

Swing を使用する非常に単純なアプリケーションを示す必要があります。State Pattern を Swing プロジェクトでどのように使用できるかについて混乱していますか?

次のいずれかの状態になる可能性のあるRequestクラスがあります。

ドラフト、提出済み、承認済み、拒否済み、InMission、完了

Requestオブジェクトの状態は、次のいずれかのメソッドを呼び出すことで変更できます。各メソッドには、いくつかのデータを特定の状態にさらに関連付けるためのいくつかの引数が含まれる場合があります。

ここでStateパターンを実装することを考えていました。私の各州のクラスは、それらに関連する追加情報を保持します。ここでStateパターンを実装する私の主なアイデアは、次のように、これらの関連のないプロパティをすべてRequestクラス自体に追加しないことです。

Stateパターンはここで実装するのに適した候補だと思いますか？

よろしく、

モッシュ

アクセスすると、ビデオに関連する情報の表を表示するページがあります。

• 埋め込みコード
• タイトル
• 説明
• 現在のギャラリー
• サムネイル画像

この情報は、ページに最初にアクセスしたときに読み取り専用です。

次のオプションがある選択メニューがあります。

• 説明を編集
• サムネイルの作成（アップロード/置換）
• 埋め込みコードを編集する
• ギャラリーを変更
• ビデオを削除する

ユーザーがオプションを選択すると、同じ初期データテーブルが表示されますが、必要に応じて関連するフォーム入力が表示されます。

たとえば、[説明の編集]を選択すると、ページが再読み込みされ、説明テキストがテキスト入力に置き換えられます。「サムネイルの作成」を選択すると、ファイルアップロード入力が表示されます。

アイデアは、すべての情報を一緒に表示することですが、一度に編集できる量を制限することです。

各データは少なくとも2つの状態のいずれかになり得るため、状態パターンが可能な解決策であることを私は知っています。

1. 表示状態
2. フォーム入力状態

しかし、私の質問は、状態パターンを使用するのはやり過ぎでしょうか？

現時点では、ページにアクセスするたびに、フォームの各部分がswitchステートメントを使用して、ページを「表示」状態にするか「入力」状態にするかを決定し、それに応じて動作します。状態パターンのデザインを実装することで、フォームを変更したり、同様のフォームを作成したりするのが簡単になるのではないかと思います。

ありがとう！

2D 描画で完全に動作する GUI を備えたアプリケーションがある場合、何を描画し、どこに触れるかを処理するためのベスト プラクティスは何ですか?

理解を深めるための例:
地図を使ったゲームがあります。このマップでは、家などを建てることができます。
拡張可能な情報バーもあります。拡張バーにはゲームに関する情報が表示され、さまざまな値を変更するためのインターフェイスも提供されます。タッチが発生した場合、マップ上の何かを変更するか、バー上の何かを変更するかを判断するために、情報バーが拡張されているかどうかを確認する必要があります。

それは状態パターンによって行われますが、「サブ状態」の可能性があるために少し複雑になる可能性があるため、それが正しいパターンであるかどうかは疑問です。

基本的な質問: State Pattern (GoF から) は、純粋なグラフィカル GUI を処理するためのベスト プラクティスですか?

興味深いまたは複雑な状態遷移を解決または単純化するために State デザイン パターンが使用された例を探しています。3 つまたは 4 つの単純な状態の例はたくさんあります。しかし、サブステートといくつかの遷移を含む実際のプロジェクトのコードはどうでしょうか? パターンの使用を実際に動機付けるコードの種類。コードへのボーナスポイントポインタ！

私は NHibernate / FNH マッピングにあまり熱心ではありませんが、状態パターンの実装を検討しており、Derick Bailey の記事のアイデアが気に入っています。

これは少し前のことだと思いますので、マッピング コードは古くなっています。FNH 1.1 用に更新するために誰か手を貸してもらえますか?

コードの残りの部分については、彼の記事を参照して ください。

どうもありがとうございました！

ポール

アプリケーションのプロファイルがあるとします。このプロファイルには、特定の 1 人のユーザーに関するいくつかのデータが保存されます。プロファイルの詳細を保持し、実行ごとに引き戻すことができます。

プロファイルは State パターンの適切な候補になりますか? そうでない場合、この種の機能をモデル化するための優れたヒューリスティックはありますか?