問題タブ [state-pattern]

Hibernateを使用したJavaでのStateパターンの実装を検索し、状況に新しい状態を追加する柔軟な方法を提供するために、列挙型を使用したソリューションへの参照をいくつか見つけました。

ここでのソリューションが気に入りました。ここでは、ConcreteStateクラス名が保存されているテーブルフィールド「state」の値から状態オブジェクトを作成するためにリフレクションが使用されます：http：//nerdboys.com/2007/06/08/state-pattern -persistence-with-hibernate /

ただし、整数値を保持するのとは対照的に、DBにcom.myCompany.myProject.asdasd.ConcreteState型の文字列値を保持するとスペースが無駄になるため、このソリューションは推奨されませんでした。したがって、次のようなテーブルに可能な状態を保存する方法があるかどうか疑問に思います。

customer_states（PK id INT、className VARCHAR）

そして、次のようにFKを状態にするために、customersテーブルを変更します。

顧客（PK id INT、name VARCHAR、FK state INT）

したがって、必要以上にディスクスペースを使用することはなく、顧客の状態の一貫性を維持して、状況に新しい状態を簡単に追加できるようにします...しかし、これをUserTypeにどのように実装しますか？

ありがとう！

状態が2つから3つしかない場合、状態パターンを使用するのはやり過ぎですか？

さまざまなデザインパターンをマスターするための継続的な探求の中で、私は「状態」デザインパターンに遭遇しました。

まず、このパターンをどこで使おうとしているのかを説明しましょう。状態を適用したいフォームがあります。私のプログラムには、Configuration、Processing、ProcessingCompleteの3つの状態があります。フォームの状態が変わると、フォームのさまざまなコンポーネントが有効/無効、表示/非表示などになります。

Stateパターンを理解すると、これらすべての変更（コンポーネントの表示/非表示、有効化/無効化など）は、フォームのインスタンスを含む別のクラス内で発生するはずです。さまざまなStateクラスがフォームのクラスから分離されている場合、Stateクラスはフォームのコンポーネントにアクセスできません。これにより、次の2つのオプションのいずれかが可能になると思います。

1. フォームのコンポーネントを公開する
2. Stateクラスをフォームの内部クラスにします

オプション（1）は悪い形だと思いますが、オプション（2）はどういうわけかStateパターンの精神に違反していると思います。私が持っていたもう1つの考えは、オプション（2）を使用することでしたが、部分的なクラス実装を使用しましたが、それでもStateパターンの精神に違反していると感じています。

どちらかの選択に対する私の気持ちは不当ですか、それとも私が考えもしなかった別の選択肢がありますか？

私はプログラミングの経験で状態パターンのいくつかの実装に遭遇し、いくつかを実行しました。さまざまなシナリオ (主に UI と解析) で使用されているのを見てきました。問題は、それらのすべてが急速な開発のプレッシャーの下で、保守や理解が困難なコードの塊になってしまったことです。これらの 1 つをリファクタリングすることを検討していますが、オンラインで適切なリソースを見つけるのに苦労しています。State Pattern の簡単な例はオンラインにたくさんありますが、さらに詳細なリソースが必要です。

だから私は探しています：

• 状態パターンを実装する際の一般的な落とし穴の例とその回避方法
• 正しく行われた状態パターンの実際の例 (一部のオープン ソース プロジェクト/フレームワークのように)
• 状態パターンの個人的な経験も大歓迎です

お時間をいただきありがとうございます

State パターンの典型的な実装から私が収集したのは次のとおりです。

問題:現在の状態に基づいて動作が変化 するオブジェクトOを表します。
解決策:
1.このオブジェクトO内の別のオブジェクトSが状態を表すとします 2. オブジェクトSはOの適切な操作を呼び出し ます 3. オブジェクトSはオブジェクトOの次の状態を決定します

私の懸念は主に#3. 状態遷移表は、基本的にすべての状態に広がっています。これらのソリューションは、非常に迅速に管理するのが面倒になるのを見てきました。これらの状態は、インジケーターではなく、状態マシンに関する情報を保持しすぎています。気になりますが、かなり合理的だと思います (
Moore machine .) 私が見た唯一の問題は、バグ修正/デバッグ中に発生することです: コードのナビゲーション/理解は、すべての状態マッピングをメモリにコミットするまで困難になります。#2

次の実装はより正確でしょうか?
状態を列挙として表し、オブジェクトは列挙が保持する値に基づいてアクションを決定します。これらstate transitionsは、現在の状態から次の状態へのマップであるテーブル (δ、状態遷移関数) にあります。これstate transition tableは、実行されるアクションも保持します ( Mealy machine )

状態パターンでは、これはどのようにモデル化されていますか?

トリガー X でステート A からステート B へ、現在のステートが A の場合は条件 C1

トリガー X でステート A からステート C へ、現在のステートが A の場合は条件 C2

これは通常どのように達成されますか？実装する必要があるガード条件がたくさんあります。

それはラッパーオブジェクトですか？または状態オブジェクト自体？

例をいくつか見てもらえますか？

プロキシパターンが構造パターンであり、状態パターンが行動パターンである理由. 新しいパターンが構造的または行動的であると見なされるべきであると判断するための基準は何ですか?

State Design Pattern を学んでいます。C# ASP.Net を使用しています (言語が適切かどうかはわかりません)。

基本的に、私のオブジェクトには状態 A、B、および C があり、異なる状態間を移動するアクションもあります: ActionAToB、ActionBtoAおよびActionAtoC。

私がやろうとしているのは、このオブジェクトを画面に結び付け、ボタンでこれらのアクションをトリガーすることですが、問題は、オブジェクトの状態に関連するボタンのみを表示し、状態のときにボタンを表示/非表示にする方法です。変化？

状態パターンに適合するエレガントなソリューション、または UI の保守を容易にする提案を探しています。

私は合理的な答えを探しています

State Design Pattern の下に来ています

編集

以下のリンクを参照してください

Java のコア ライブラリの GoF デザイン パターンの例