問題タブ [state-pattern]

デコレータや状態パターンに最適だと思う問題を解決している最中です。高レベルの設定は、サンドイッチメーカーやディスペンサーのようなもので、一定量の材料といくつかの異なる種類のサドニッチを作ることができます。各成分には、それに関連するコストがあります。クライアントは、特定のスイッチを作るために材料を選択するために機械を使用する誰かであり、機械はそれを分配します。

これまで、デコレータパターンを使用して材料とさまざまな種類のサンドイッチを作成しました。

各成分はこれでモデル化されています：

さらに、具体的な成分は次のようになります。

特定の種類のサンドイッチは、次のようにモデル化できます。

したがって、クライアントは次のような特定のサンドイッチを作成します。

次のステップとして、自動マシンとして機能するディスペンサーオブジェクトを作成します。このオブジェクトには、特定の数の材料（一般的な単位で測定）が事前にロードされており、ユーザーはボタンを押して事前のいずれかを選択できます。 -選択を設定します：

例えば

• BLT：トマト1単位、レタス1単位、ベーコン1単位、パン1単位
• SUB：1ユニットのミートボール、1ユニットのチーズ、1ユニットのitalian_sauce、1ユニットのパン
• 等..

私のディスペンサーマシンには、材料ごとに固定数のユニットがプリロードされています

• トマト：10
• レタス：10
• ベーコン：10
• 等..

また、ユーザーが特定の種類のサンドイッチを選択するためのボタンのリスト：

• 1-BLT
• 2-SUB
• 3-バーベキュー
• ..等

材料の内部容量を追跡し、たとえば、別のBLTを作成するのに十分なベーコンが残っていないことをユーザーに伝えることができるようにするという考え方です。

さて、私の最初の考えは、状態デザインパターンに基づいてDispenserオブジェクトを作成することですが、IngredientクラスのオブジェクトをDispenserクラス内のある種のストレージと組み合わせようとして問題が発生しました。最初は、名前/値のマップが成分タイプ/成分量のペアになっています。しかし、使用するたびに自動的にデクリメントできるように、これらのパターンを組み合わせる方法がわかりません。

そのような概念をどのように進めて実装するかについて、一般的な考えはありますか？まず第一に、私はデコレータと状態パターンで正しい軌道に乗っていますか？より効率的なアプローチはありますか？問題を明確に説明できたと思います。

どんな方向性もありがとう、私はどんな考えにも感謝します

次のクラスをリファクタリングするのに助けが必要でした。

以下は、スイッチのさまざまな操作を含むクラス操作です。スイッチステートメントを避けたいと思います。ポリモーフィズムと状態パターンの使用に関する記事はほとんど読みませんでした
。操作を抽象クラスとして使用するか、インターフェイスを実装します。
この場合、どのタイプのリファクタリングが
ポリモーフィズムまたは状態パターンに役立つか知りたいですか?
そして、いつそれらを使用するのですか？

呼び出しコードは次のようになります。

参照スレッド:
リンク
リンク
..その他多数。

特定のプロセスをモデル化しようとしていますが、状態パターンが適切である可能性があると考えています。Stateが私のニーズに合うかどうか、そしてそれを永続化メカニズムとどのように組み合わせる必要があるかについて、フィードバックをお寄せください。

Pagesなどの多数のオブジェクトを持つCMSがあります。これらのオブジェクト（Pagesの例を使用しますが、ほとんどのオブジェクトに当てはまります）は、いくつかの状態の1つになります。3つの例は次のとおりです。未公開公開済みリワーク

未公開の場合、編集可能です。公開されると、編集できなくなりますが、リワーク状態に移行できます。リワーク状態では、それらは再び編集可能であり、再公開できます。

明らかに、これらのページが編集可能かどうかの決定は、UIではなくモデル自体で行う必要があります。そのため、Stateパターンが頭に浮かびました。ただし、オブジェクトのプロパティに値が割り当てられないようにするにはどうすればよいですか？各プロパティセッターをチェックするのは悪い考えのようです。

これをどのように機能させるかについてのアイデアはありますか？これにはもっと良いパターンがありますか？

通常のステート マシンでステート パターンを使用していました。[ A -> B ]、[ B -> C ]、[ A -> C ]から行けるようにしたかったのです。今、私たちのドメインには新しいルールがあり、[C -> A] からも移動する必要がありますが、以前に B に行ったことがない場合に限ります。したがって、メモリのある状態があります。考えられる解決策は 2 つあります。

1. B の後に C を意味する新しいステートCBを作成し、[ A -> B ]、[ B -> CB ]、[ A -> C ]、[ C -> A ]のルールを設定します。
2. Context には以前の状態 (StateHistoric と呼びましょう) と遷移が行われた日付 (状態履歴も顧客のドメイン要件です) のリストがあるという事実を使用し、これらのルールを使用します [ A -> B ]、[ B -> C ]、[ A -> C ]、[ Bが Context.StateHistoric にない場合はC -> A ]。

状態パターンのメモリを使用するより正しい方法は 2 つのうちどれですか? （またはこれら2の別の代替手段）

ありがとう

ステート マシンのモデル化に関する小さな問題があります。

私は少しの知識工学を行い、状態と状態遷移を決定する原始的な決定論的ルールのセットを「リバースエンジニアリング」しました。

ベストプラクティスが何であるかを知りたい：

• 状態と状態遷移を厳密にテストして、システムが不確定な状態にならないようにする方法。

• 状態遷移要件を強制する方法 (たとえば、stateFoo から StateFooBar に直接移動することは不可能であるべきです。つまり、各状態に、遷移可能な状態に関する「知識」を吹き込むことです。

理想的には、可能な限りテンプレートを使用して、クリーンなパターン ベースのデザインを使用したいと考えています。

私はどこかから始める必要があります。

1つの質問ですが、私は2つの解決策を探しています。

• 静的
• 動的

静的とは、私がすべての状態を知っていることを意味します。動的とは、エンドユーザーが状態を定義できるため、状態がわからないことを意味します。

静的
ビュー、ビューモデル、およびアクションを作成および整理する方法は？状態パターンがそのシナリオに適していることは知っていますが、ビューモデルからデータを渡してエンティティに配置するにはどうすればよいですか？各アクションは1つの状態に責任がありますか？次の状態の可能な選択肢が複数ある場合はどうなりますか？

値を投稿して文字列として送信された状態に対して適切なアクションを選択するにはどうすればよいですか？

適切に投稿されたデータをエンティティの特定のアクションに一致させる方法（状態パターンを見てください）？

動的
エンドユーザーが独自の状態を作成できる場合はどうなりますか？例：アプリにはワークフローのようなものがあります。私が上記と同じ状況にあると仮定します。私はそれらを知らないので、私はそれぞれの州の見解を持っていません。

質問...同じですが、解決策は異なるかもしれません...しかし、解決策は何ですか？

以下は、状態パターンの私の実装です。NHibernate を使用して State オブジェクトをデータベースに永続化するために、各状態クラスに列挙値を割り当てています。これは、エンティティのプライベート フィールドとして格納され、データベース テーブルの整数フィールドにマップされます。

アプリケーション全体で状態パターンを使用するので、これが適切な実装であるかどうかを知りたいのですが、最初にそれを正しく取得したいと考えています。ありがとう

State パターンについて読んでいます。私はまだ始めたばかりなので、もちろんウィキペディアの記事全体を読むことから始めます。

この記事の両方の例に、一般的な State のメソッド/関数用の基本抽象クラスまたは Java インターフェイスがあることに気付きました。次に、ベースから継承し、それらのメソッド/関数をさまざまな方法で実装するいくつかの状態があります。次に、State 型のプライベート メンバーを持ち、いつでもいずれかの実装のインスタンスと等しくなる Context クラスがあります。そのコンテキストクラスも同じメソッドを実装し、それらを現在の状態インスタンスに渡し、状態を変更する追加のメソッドがあります (または、設計によっては、状態の変更が実装されたメソッドの 1 つに対する反応である可能性があることを理解しています)。 .

このコンテキスト クラスが、一般的な State ベース クラス/インターフェイスを特に「拡張」または「実装」しないのはなぜですか?

多くの状態を持つステートマシンがありますA--B--C--D--E。CたとえばA、ある条件が検証された場合など、多くの遷移があります。すべての状態に対して、抽象クラスStateを拡張するクラスがあり、すべての遷移メソッドを状態メソッドに委譲するマネージャーがあります。問題は、「ステートがマネージャーの遷移メソッドを直接呼び出すことができるか?」ということです。インターネット上で見たのは、遷移が何回発生したかを正確に知るメイン クラス (つまり、、、、) がある例insertQuarter()だけです。これを行う唯一の方法は、状態でマネージャー遷移メソッドを呼び出すことです。これは間違っているか悪い習慣ですか？ejectQuarter()turnCrank()dispense()

よろしくお願いします トビア