問題タブ [state-pattern]

私が構築するソフトウェアには、さまざまなステータス間の「アプリケーション」の切り替えが多く含まれます。アプリケーションのステータスに応じて、実行できる特定のタスクがあります。ステータスとして列挙型を使用することを考えていました

しかし、ステータスは頻繁に更新/並べ替えられるため、データベースでルックアップテーブルを使用するのが良いと思いました。

私の場合、私は次のようなことをする必要があります

上記の場合は列挙型の方が簡単だと思います。ただし、ステータスの並べ替え順序や説明を更新する場合は、かなり難しいでしょう。

リフレクションを使用して、ルックアップテーブルの値に基づいて列挙型を動的に作成する必要がありますか？または、状態パターンを使用する必要がありますか？列挙型の反射で私が目にする問題は、パフォーマンスへの影響です。そして、状態パターンは多くの冗長なコードを生成する可能性があります。

どう思いますか？前もって感謝します！

私はたくさんのものを描くパネルを持っています。描画を効率的にするために、何かが起こるたびにすべてを描画する必要がないように、BufferedImage を使用しています。

私の paintComponent は「if」ステートメントのみを必要とします:

状態パターンを使用するというアイデアは気に入っていますが、それを使用する適切なタイミングがわかりません。私は、extraOnly にブール値を設定しなければならないという考えが好きではありません。また、パターン フィーバーも発生している可能性があります :)。各状態には draw(Graphics g) という 1 つのメソッドしかありません。

これは MVC パターンでのアプリケーションのビュー部分であるため、状態パターンの使用が間違っているかどうかもわかりません。状態はビューではなくモデルの一部であるべきではありませんか?

Java SAX パーサーでいくつかの xml を解析する必要があります。忙しかったので、ここで状態パターンを使用できることがわかりました。

xml ドキュメントの構造に似た、明確な状態と状態遷移が定義されています。

状態パターンを実装するには、インターフェイス (または抽象クラス) を定義する必要があります。最も明白なインターフェイス メソッドは次のとおりです。

しかし、私が遭遇する問題は、情報を返す方法です。1 つの構造の xml ドキュメントの複数のレベルからの情報が必要です。

これは xml ドキュメントの一部です

状態パターンがここに収まるという私の仮定は正しいですか? もしそうなら、ここでそれを実装する最良の方法は何ですか?

iPhone アプリケーション (私の場合は比較的軽量なユーティリティ アプリケーション)の状態パターンは、メモリを使いすぎていませんか?

私が理解しているように、状態パターンはいくつかのクラスを使用します。これらのクラスは異なる状態を表します。さまざまな状態オブジェクトはすべてインスタンス化され、状態が必要になるまでさまざまなポインター変数に格納され、必要になった時点でcurStateオブジェクトに設定されます。

各状態オブジェクトを遅延読み込みして、メモリと読み込み時間を節約できると思います。アプリがメモリ警告を受け取った場合は、オブジェクトを解放できます。

しかし、私が知りたかったのは、このパターンは、iPhone OS アプリケーションで一般的に使用するにはメモリを使いすぎないかということです。iPhone 開発者はこのパターンから離れるべきですか? iPhone OS により適した別のパターンはありますか?

次の状態パターンの実装については、疑問があります。

Order オブジェクトがあります。簡単にするために、数量、productId、価格、およびサプライヤーがあるとします。また、注文が遷移できる一連の既知の状態があります。

• 状態 a: 注文は新規です。数量は > 0 で、productId が必要です。価格とサプライヤーはまだ割り当てられていません。
• 状態 b: 誰かが注文をチェックします。キャンセルするか、サプライヤを割り当ててもらうことしかできません。
• 状態 c: サプライヤーは、クライアントに請求する価格のみを記入できます。
• 状態 d: 注文がキャンセルされました。

1. Order.isValid() は状態間で変化します。つまり、一部の操作ができない状態です。void setQuantity
   (int q) {
   if (_state.canChangeQuantity()) this.quantity = q;
   それ以外の場合は例外をスローします。
   それとも、各状態を取得してsetQuantity
   操作を実装する必要がありますか? その場合、値はどこに格納されますか? 順番で、それとも状態で？後者の場合、各状態遷移でデータをコピーする必要がありますか?

2. orderProcessor.process(order) は、order.IsValid をチェックし、注文を何らかの状態に遷移させ、それをデータベースに保存し、いくつかのカスタム アクションを実行するオブジェクトです (状態によっては、管理者に通知され、他の状態ではクライアントに通知されるなど)。州ごとに 1 つずつ持っています。
   StateAOrderProcessor では、注文を確認した人にメールで通知され、注文は状態 b に遷移します。
   これで、状態遷移が Order クラスの外にプッシュされます。つまり、Order には「setState」メソッドがあり、各プロセッサがそれを変更できます。外部から状態を変更するこのことは、いいことではありません。そうですか？

3. もう 1 つのオプションは、すべての検証ロジックを各状態のプロセッサに移動することですが、注文の数量がいつ変更されたかを追跡して、その操作が現在の状態で有効かどうかを確認する必要があります。 それは私に一種の貧血を残します。

皆さんどう思いますか？このデザインをより良くするためのアドバイスをいただけますか？

「アーキテクチャパターンは、ソフトウェアシステムの基本的な構造組織スキーマを表します」。

有限状態マシン（特に多くのリアルタイムシステムや組み込みシステム）として説明できるソフトウェアシステムがあります。最初の段落の「アーキテクチャパターン」の説明を考慮すると、特定のケースでは、「状態設計パターン」は「アーキテクチャパターン」にもなり得ますか？

この質問は、「状態設計パターン」を含む後輩の開発者と設計ドキュメントについて話し合ったときに受け取りました。アプリケーションは主に有限状態マシンであるため、「状態設計パターン」は「建築設計パターン」と見なすことができるという質問に「はい」と答えました。とにかく、グーグルで見ると、この質問に関連する特定の議論が見つからないので、私の答えが正しかったかどうかはわかりません。

正解は何ですか（それを与えることが可能である場合）？あなたの答えの根拠は何ですか？

よろしくお願いします。

私はJavaで古典的な状態のデザインパターンを使用し、それをルビーに変換する際にいくつかの問題に直面している実用的なソリューションを持っています。私は Ruby を初めて使用しますが、問題は動的言語でパターンを実装する方法の違いにあると私は信じています。

私のインターフェイスは、モデルがすべての状態で実行できるアクションを記述しています。

次に、状態インターフェイスを実装し、ロジックの具体的な状態を作成します。

ご覧のとおり、各具体的な状態はモデルに到達し、その状態を変更できます。カプセル化の問題を回避するために、現在の State への参照も持つ Model クラス内で具体的な状態をインスタンス化します。

クライアントは次のようにモデルを使用します。

上記のJavaはすべて簡単だと思いますが、現在、この設計をRubyに移植しようとしています。タイプチェックの違いと、モジュールとミックスインが Java のインターフェースとは対照的に Ruby でどのように機能するかを認識しています。

つるはしの本で、Ruby の State デザイン パターンについても知りました。今、私はそのような変換を試みる最良の方法について少し混乱しています. 私はまだ Java ボックスの中で考えています。各状態の具体的な実装を別の .rb ファイルに入れ、それをクライアント クラスで要求する必要があるかどうか疑問に思っています。

delegate.rb ライブラリを使用せずに上記を実装する方法はありますか?

私の改宗をどのように開始するかについての提案は、熱烈に歓迎されます.

概要：

状態パターンを使用しているプログラムの設計を改善しようとしています。問題の簡単な説明、クラス図の画像/現在の設計の説明、関連するクラスのヘッダー コードを投稿します。

問題：

プログラムに状態パターンのバリエーションを使用しています。このバリエーションでは、「状態」と「イベント」という 2 つの抽象クラスを利用する「コントローラー」があり、これらのクラスからいくつかの具象型が拡張されています。これら 2 つの抽象クラスは、イベントのタイプと現在の状態に基づいて変化する「イベント」への応答を実行するために使用されます。各状態には、各具体的なイベント タイプを取得するためにオーバーロードされた「ハンドラー」関数があります。

「コントローラー」には、発生した「イベント」(具象クラス) のリストを含む、タイプ「イベント」(抽象クラス) のキューが含まれます。コントローラーは、各イベントを一度に 1 つずつ「処理」し、キューからイベントを取得し、特定のタイプのイベントの状態のハンドラーに渡します。

問題は、正しい型を取得してイベントを状態の適切なハンドラーに渡すために、イベントを正しい具象型にダウンキャストする必要があることです。現在、各具体的なイベント タイプによって実装され、そのイベント タイプを表す整数を返すメソッドをクラス 'state' (getType()) に追加することでこれを実現しています。ただし、この方法は非常に「非エレガント」であり、列挙型を使用して「スイッチ」ブロックと「ダウンキャスト」を駆動することになります。これはあまり良い設計方法ではありません。

このデザインを変更して、イベントの状態への受け渡しをよりエレガントにするにはどうすればよいですか?

クラス図

ヘッダー コード

Strategy デザイン パターンと State デザイン パターンの違いは何ですか? 私はウェブ上でかなりの数の記事を読んでいましたが、違いを明確に理解できませんでした.

誰かが素人の用語の違いを説明できますか?