問題タブ [state-pattern]

here's a programming style question about the best strategy to map input keys to actions in a class that implement the state pattern.

I'm dealing with two classes:

The first implements the state pattern, which controls a multi-state physical device:

The second is a KeyListener that retrieves all keyboard input and calls the appropriate action from the device controller when a pressed input key matches a (for the time being) hard-coded bindings table:

Is there a best-practice coding style to bind the keys to the actions in the controller ? Do I have to go through a switch statement, as in the sample code ? It seems to me that this solution is somewhat dirty code: isn't the state pattern supposed to eliminate unmaintanable if and switch control structures ?

Thank you for your suggenstions.

Head First Design Patternsを読んでデザインパターンを学んでおり、StatePatternの章を終えたところです。しかし、私が得られないことが1つあります。

この本では、状態を持つクラスはContextと呼ばれ、実際の状態はStateインターフェイスを実装します。リクエストが本に与えられたら、ここのメソッドを使用して状態を変更します。

1. コンテキストはリクエストを受け取ります。
2. Contextは、所有するStateでhandle（）メソッドを呼び出し、要求をStateに渡します。
3. 状態はリクエストを処理し、変更する必要がある場合はコンテキストに状態を設定します。これを行うために、州はフィールドとしてコンテキストを持っています。

ただし、これは2つのクラス間にいくらか「再帰的な」結合を与えるように思われ、直感的ではありません。私が彼らの解決策を読んでいないのなら、私は次のデザインを好むでしょう：

1. コンテキストはリクエストを受け取ります。
2. Contextは、所有するStateでhandle（）メソッドを呼び出し、要求をStateに渡します。
3. 州はリクエストを処理し、州を返します。別の状態であるかどうかは、リクエストの処理方法によって異なります。
4. コンテキストは、独自の状態を返された状態に設定します。

私が考えることができる長所と短所：

1. 変化する可能性のあるすべてのものをStateクラス、Context、およびStateに入れると、互いのフィールドを覗き見する必要がなくなるため、より分離されます。
2. 州のクラスは大きくなる可能性があります。
3. 状態は、異なるコンテキスト間で簡単に再利用できない場合があります。ただし、Stateは、Stateインターフェースを実装する抽象クラスとして実装でき、抽象状態をサブクラス化するContextsによって使用される具体的なStateを持つことができます。

最初のもの（ Head First Design Patternsで使用されている）を優先する必要がある、または2番目の選択肢も有効で実際に使用されている、または私が見なかった重大な欠陥がある可能性がある特定の理由はありますか？

すべての入力と、読んで返信してくれてありがとう！

Entity Framwork 4.1、Code First、FluentAPIを使用してエンティティをマッピングしようとしています。私のシナリオは、抽象クラスを使用して状態パターンを実装していることです。私の実装を参照してください：

//私の契約

そして今、SaleStatusの私の現在のマッピング：

プロジェクトを実行すると、次のメッセージが表示されます。

指定されたスキーマが無効です。エラー：（107,6）：エラー0075：キーパーツ：タイプSaleStatusの「IdSaleStatus」が無効です。キーのすべての部分はnull許容でない必要があります。

誰でも私を助けることができますか？

ありがとう、

よろしくお願いします。

ミシェル・マガリャエス

現在取り組んでいるプロジェクトには多くの問題があります。このプロジェクトは 10 年以上前のもので、90 年代に非常に人気があった商用 C++ フレームワークの 1 つに基づいていました。問題はステートチャートにあります。このフレームワークは、状態パターンの非常に一般的な実装を提供します。各状態は個別のクラスであり、エントリ時のアクション、状態内のアクションなどがあります。受信したイベントに従って現在の状態を設定するスイッチがあります。

悪魔は細部に隠されています。そのプロジェクトは巨大です。2000KLOCくらいです。確かにステートチャートが多すぎます (ステートチャートを使用して実装された「for」ループを見たことがあります)。さらに...フレームワークでは、ステートチャートを別のステートチャートに埋め込むことができるため、ネストのレベルが7つ以上のステートチャートが多数あります。ステートチャートは異なるスレッドで実行され、ステートチャート間でイベントを送信できるため、多くの同期の問題 (およびインターフェイスの大きな混乱) があります。

私は、この問題の規模が圧倒的であり、どう対処したらよいか分からないことを認めなければなりません。私の最初のアイデアは、ステートチャートからできるだけ多くのコードを削除して、別のクラスに入れることでした。次に、これらのクラスをステートチャートから委任して、仕事をします。しかし、その結果、論理的に特定の機能を持たない多くの個別の関数が作成され、ステートチャート アーキテクチャの変更には、そのクラスと関数の変更も必要になります。

だから私は助けを求めています：これを修正するのに役立つ本/記事/魔法のアーティファクトを知っていますか？少なくとも、隠れた依存関係を導入することなくステートチャートからできるだけ多くのコードを分離し、分離されたコードを保守可能、テスト可能、および再利用可能に保ちたいと考えています。

これを処理する方法について何か提案があれば、私に知らせてください。

アプリケーションに登録ページがあります。3 つの状態と 1 つのエラー状態 (エラーが発生した場合) があります。

1. 基本情報の入力
2. パッケージを選択
3. 感謝を言います
4. エラー

ここで状態パターンを使用したいと思います。最初に、問題のないコンソール アプリケーションを作成しました。MVC アプリケーションにこのロジックを実装したいのですが、構造について混乱しています。必要なビュー、モデル、およびコントローラーの数と、ロジックを配置する場所を意味します。

とOrderの 3 つの異なる状態になるクラスがあるCheckedStateとPaidStateしOrderedStateます。

ステート マシンは、標準のステート デザイン パターン (Gof) を使用して実装されます。

通常、これをどのように単体テストしますか? 各ステート クラス ( CheckStateFixture、 、...) にフィクスチャを使用し、コンテキスト クラスにPaidFixture別のフィクスチャ ( ) を使用しますか? それとも、すべての単体テストを配置するOrderFixtureコンテキスト クラス ( ) に対して 1 つのフィクスチャのみを使用しますか?Order

私は C# での状態パターンの実装に不慣れです。実装方法に関する情報を提供していただけますか。

ステート パターンを使用して、C# でステート マシンをリファクタリングしています。現在、私の状態マシンには 5 つの状態が含まれており、状態を前後に移動することしかできません。つまり、状態 1 から状態 2、3、4 に移動して、最終的に状態 5 に到達する必要があります。

やるだけで前に進めます

先に進むたびに新しい状態を作成しますが、すべての状態が作成された後、および/または前に戻りたい場合は、新しい状態だけでなく、同じ状態に移動する必要があります。どうやってやるの？シンプルにする良い方法はありますか？

すべて同様の動作をするオブジェクトの階層があります。動作を POCO 定義から分離したいと考えています。動作はオブジェクトをさまざまな状態に移動することを表しているため、これは状態パターンの仕事のように思えます。ただし、各オブジェクトの動作がわずかに異なる可能性があるため、関数ごとに 1 つの定義があるほど単純ではありません。

たとえば、抽象基本クラスに基づいて、次のクラスがあるとします。

階層は、さまざまなタイプのオブジェクトを表します。また、オブジェクトはすべて同じ基本的なワークフロー (送信済み、承認済み、実行済み、クローズ済み) に従っているとしましょう。

現在、各関数の動作も階層的です。つまり、Class1 で関数 Approve() を呼び出すことは、BaseClass から継承された動作を呼び出すことと同じである必要がありますが、Class2 は Approve() 関数をオーバーライドします。これは、そのタイプが異なる承認に従うためです。処理する。

State Pattern をこれらのオブジェクトに適用しようとして迷っています。関数をオブジェクト自体に配置し、そのように継承することを選択できます。これは正常に機能しますが、POCO 設計が壊れます。オブジェクトの種類ごとに switch ステートメントを使用して Approve() 関数を実装することもできますが、それでは多態的な設計ができなくなります。

状態パターンを多層ポリモーフィック オブジェクト定義に適用し、設計原則との一貫性を維持するにはどうすればよいですか。

更新：明確にさせてください。オブジェクトに作用する以外のことを行う関数はPOCOに属していないと思います。例: 承認機能は、オブジェクトの状態を変更するだけでなく、電子メールを送信し、他のシステムでイベントをトリガーします。多分それは私だけです。

私が実装している特定の状態パターンに関して、最適な OO 設計アプローチがどうあるべきかについては確信が持てません。次の点を考慮してください。

私が躊躇しているのは、newここでの単語の使用法です。new SomeState()を別の状態でインスタンス化するか、または別のnew SomeRequest()内でインスタンス化します。これは、州とその兄弟、および とs の間の高い結合を生み出すように私には思えます。ControllerStateControllerState

要件は次のとおりです。

1. を追加するなど、新しい状態を追加できる必要がありSniffingStateます。

2. また、既存の状態を新しい状態に置き換えることが可能でなければなりません。たとえば、別のアクションを実行する別OffLeachStateのものに置き換えることができるはずです。OffLeashState例（何らかの理由でコードがフォーマットされません）：

   public class OffLeachState2 extends DogState {
   public void seeCat(Cat cat) {
   if (dog.knows(cat)) {
   // 犬は "PlayWithCatState" に変わります
   // 猫は "PlayWithDog" リクエストを受け取り
   ます } else {
   // 犬は " に変わりますChaseAnimalState"
   }
   }
   }

3. World最後に、クラス内のすべての変更をログに記録する必要があります。つまり、World クラスには、進行中のすべてを追跡するロガーがあるということです。これは、World クラスがモデルでありnotifyObservers()、ビューが何かを行うことを認識できるように を起動する必要があるためでもあります。

私の質問は、状態、要求などをどこに保存する必要があるかです。例えば：

1. に状態「ゲッター」が必要Dogですか? たとえばdog.getBarkingState()、、、dog.getOnLeashState()など? Dogこれは理にかなっているように見えますが、クラスが変更に対して抵抗力を持つわけではありません。つまり、新しいクラスを追加するたびに、それにゲッターがあるDogStateことも確認する必要があります。Dogまた、 はWorldこれらの変更を認識しないため、変更をログに記録したり、オブザーバーに通知したりしません。

2. と呼ばれるクラスが必要で、DogStates実行できますDogStates.getBarkingState()か? 繰り返しますが、上記の問題と同様の問題です。

3. World彼らはクラスの一員であるべきですか？たとえば、world.setDogState(dog, world.getDogBarkingState()? Worldこれにより、ロギング/更新の問題は解決されますが、クラスの責任が大きくなりすぎます。

4. たとえば、それらの組み合わせである必要がありますかworld.setState(dog, dog.getBarkingState()？これは良いかもしれませんが、型の安全性は保証されません。たとえば、Dogオブジェクトを で渡すことができますCatStateが、違いはわかりません。

解決策 #4 が私には最善のように思えますが、この問題について他の意見が欲しいです。

同じ質問がオブジェクトにも当てはまりRequestます。Requestもともと、オブジェクトに関連付けられた文字列で sを送信したかったのworld.sendRequest(dog, DogRequests.SEE_CAT)ですが、 cat オブジェクトを引数として渡すことができませんでした。

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

これは少しトリッキーになってきています。アプリケーションで状態パターンを使用して状態を管理しています。アプリケーションで各状態のインスタンスを 1 つにしたいのですが、各状態クラスをシングルトン クラスとして作成したくありません。私が考えているもう 1 つのアプローチは、StateLocator クラスを作成することです。StateLocator はシングルトンにすることができ、すべての状態のインスタンスを保持できます。StateLocator が良い解決策に見えるかどうか、または状態のインスタンスを 1 つだけ持つことができ、シングルトンを回避できる可能性がある他の解決策があるかどうかを教えてください。

どんな助けでも大歓迎です。例えば