問題タブ [strategy-pattern]

私のアプリケーションには、オブジェクトに対してさまざまな戦略があります。それを実装するための最良の方法は何ですか？理想的には、たとえばリレーショナルデータベースから戦略の実装を動的にロードしたいと思います。ただし、その方法はわかりません。最善のアプローチは何ですか？

たとえば、戦略Strategy123をオブジェクトに適用したいとしますMyObj。データベースからオブジェクトをロードし、そのIDを使用して123逆シリアル化し、Strategyクラスを取得して、で使用しMyObjます。

このアプローチは、メンテナンスに関していくつかの問題を抱えている可能性があります。一見簡単に聞こえますが、たとえば戦略のインターフェイスが変更された場合など、長期的には苦痛になる可能性があります。

他にどのような解決策がありますか？ストラテジーが変更された場合、または新しいストラテジーを追加した場合に、コードを変更してアプリケーションを再デプロイする必要がないように、ストラテジークラスをコードベースの外部に保持できるソリューションが必要です。

次のように、戦略パターンを配置し始めたコードがあります。

インターフェイスには Calculate メソッドがあるだけです。実装後、3 つの具象型すべてが Calculate メソッドと同じ名前の 2 つのプロパティの同じコードを持ち、異なる値が設定されていることが判明しました。

したがって、重複を取り除くために、インターフェイスを抽象クラスにし、メソッドとプロパティをそこに移動しました。具象型の構築内からそれぞれの値を使用して基本プロパティを設定するだけです。

パターンは厳格なルールではなく、単なるガイドラインであることがわかりましたが、これをガイドラインから遠く離れて歪めているので、見なければならない別のパターンがあると思わずにはいられません。

新しい「戦略」を簡単に追加できるように、他のアプローチを提案してください。これらの新しいケースのいくつかでは、ロジックを変更する必要があることが判明する可能性があります。では、コードを繰り返すことなく、後で変更できる柔軟な設計を実現するにはどうすればよいでしょうか?

ありがとう。

複数の型のインスタンスの内部ハッシュコードを計算する必要があります (一部の型は互いに派生しています)。ここでは 2 つの側面が動的であり、独立して変化する可能性があります。ハッシュを要求するクライアントだけが、どのハッシュ アルゴリズムが使用され、どのプロパティが含まれるかを知っています。

1. ハッシュ計算に使用される実際のアルゴリズムは変更される可能性があります。
2. ハッシュ計算で考慮すべき各タイプのメンバーは変更される可能性があります。

これらの要件に合わせて型をどのように設計しますか?

研究上の理由から、内部の「戦略パターン」の実装を特定するために Javadoc を検索しています。Javadocクラスから実際に継承された2つのクラスFilterInputStream、クラスBufferedInputStreamとDataInputStream. 継承されたクラスはクラスのread()メソッドをオーバーライドしますFilterInputStream。ここで、 「戦略パターン」に従ってJavadoc、メソッドが本体read()で呼び出される別のクラスからメソッドを見つける必要があります。誰でも私を助けてくれますか？

PS Javadoc内に戦略パターンの他の実装がある場合は、教えてください。

前もって感謝します

私はこの質問が以前に尋ねられたことを知っています（例えば、ブリッジパターンと戦略パターンの違いは何ですか？）。

しかし、誰かが明確な例を使用して、違いは何であり、どのような場合に一方を他方から選択する必要があるのか​​を説明してもらえますか？概念的な理論ではなく、より実用的な「現実の」シナリオをいただければ幸いです。

ストラテジーパターンを特定の状況に適用しようとしていますが、各具体的なストラテジーを、そのデータを提供するコンテキストオブジェクトに結合しないようにする方法に問題があります。以下は、いくつかの異なる方法で発生するパターンの単純化されたケースですが、同様の方法で処理する必要があります。

特定の時間枠に関連するデータを提供するオブジェクトがありAcquisitionます。基本的には、さまざまなハードウェアを使用して収集された一連の外部データです。含まれているデータの量のためにすでに大きすぎるので、それ以上の責任を負わせたくありません。ここで、このデータの一部を取得する必要があります。いくつかの構成に基づいて、対応する電圧をハードウェアに送信します。

したがって、次の（非常に単純化された）クラスを想像してください。

ここで、すべての具体的な戦略クラスを私の取得クラスに結合する必要があります。これは、アプリケーションの中核であるため、変更される可能性が最も高いクラスの1つでもあります。これは、クラス内の巨大なswitchステートメントであった古い設計をまだ改善したものです。Acquisitionデータの種類ごとに変換方法が異なる場合があります（Batteryは単純なパススルーですが、他のデータはそれほど単純ではありません）。そのため、戦略パターンなどを使用する必要があると思います。

IAnalogOutputterまた、最終的な実装では、インターフェイスではなく抽象クラスになることにも注意してください。これらのクラスは、ユーザーが構成可能でXMLファイルにシリアル化されるリストに含まれます。リストは実行時に編集可能で記憶されている必要があるため、Serializableは最終的なソリューションの一部である必要があります。それが違いを生む場合に備えて。

最も重要なクラスの1つに結び付けずに、各実装クラスが機能するために必要なデータを確実に取得するにはどうすればよいですか？それとも、私はこの種の問題に完全に間違った方法で取り組んでいますか？

特に戦略パターン (デザイン パターン、GoF94) について考えています。ここでは、戦略コンストラクターに渡されるコンテキストは、戦略自体を (メンバーとして) 含むオブジェクトである可能性があることが示唆されています。ただし、次の場合は機能しません。

次に、StrategyBase とそのサブクラスが Analysis のデータ メンバーにアクセスします。

Strategy* クラスを定義する前にインスタンス化できないため、これは機能しません。しかし、その定義は分析の定義に依存します。それで、あなたはこれをどのように行うべきですか？ChooseStrategy を次のように置き換えます

また、analysis.h と strategy.h の両方を #include するファイルでインスタンス化を行いますか? ここでのベストプラクティスは何ですか?

サービスから返されたレコードのリストを処理する必要があります。
ただし、レコードの処理アルゴリズムは、レコードの特定のフィールドに基づいて完全に変わります。
これを実装するために、メソッドを 1 つだけ持つ IProcessor インターフェイスを定義しました。

IProcessorそして、さまざまなタイプの処理に対して の具体的な実装が 2 つあります。
問題は、すべての実装をIProcessor同時に使用する必要があることです..IProcessor全体を駆動するエンジンクラスにどのように挿入しますか:

これは私が現在行っていることです..そして、きれいに見えません。
この設計をどのように改善できるかについてのアイデア..おそらくIoCを使用していますか?

私はパターンを設計するのが初めてで、戦略パターンを学ぼうとしています。こことoodesign.comでたくさんの例を読んだ後、私はその意図をかなり理解しています. ただし、私が見つけたほとんどの例は、Java、C#、または C/C++ にあります。これらの言語はより構造化されており、クラスなどを持つ必要があります。スキームのような動的言語になると、そのようなパターンをどのように実装できるかを想像するのに苦労します。誰かが私に例を見せてもらえますか?

「ギャング オブ フォー」戦略であるクラスは、完全にステートレス (つまり、フィールドがない) である必要がありますか、それとも不変の状態 (つまり、最終フィールド) を含むことができますか?