問題タブ [strategy-pattern]

戦略パターンを実装するとき、使用する戦略を決定するコードをどこに配置しますか? いくつかのサンプル疑似コードが役立ちます。

更新：もう1つの質問を追加しました（質問＃4）。

こんにちは、みんな、

私は自分でカスタムメールユーティリティを構築しています。ここで、単一責任の原則に従うために、次のクラスが必要です：MailerSender、MailProvider、EmailObject。MailSenderは代理人です。以下で確認してください。

MailSenderには、電子メールの送信作業を行うIMailProvider電子メールプロバイダーが必要です。以下でそれを見つけてください：

上記でいくつかの戦略を定義しましたが、任意の数に拡張できます。MailSenderはいつでもプロバイダーを変更できるため、戦略パターンを効果的に実装しますか？

EmailObjectは、関連する電子メール情報を含むPOJOです。

クライアントコードは次のようになります。

私の質問は次 のとおり

です。1。戦略パターンを実装しましたか？
2.このデザインは良いですか？MailProviderがEmailObjectを認識することは意味がありますか？
3.後で添付ファイルが必要な新しいEmailObjectがあった場合はどうなりますか？
4.クライアントコードは、MailSenderを作成する前に特定のMailProviderを取得する必要があります...これは意味がありますか？

各製品には、割引、マーチャントごとのディスカウント、マーチャントごとのボーナス、月間ディスカウントなどのコスト計算ツールが関連付けられています。将来的には、さらに多くのコスト計算ツールが追加される予定です。

具体的な製品クラスと、各コスト計算用の多くのデコレーターがあります。電卓は、商品のマーチャント ID、カテゴリ ID、色などの商品のプロパティによって計算を適用することを決定するため、すべての商品ですべての電卓を使用する必要があります。

そして、私たちのシステムには計算が必要な何百万もの製品があります。したがって、装飾された電卓をキャッシュする方が適切です。実行時に各製品エンティティを装飾するとコストがかかるためです。しかし、これはデコレータ パターンでは困難です。私たちの状況でこのパターンを使用するのは匂いのようです。

何を指示してるんですか？デコレーター、戦略、または責任連鎖パターンを使用する必要がありますか? またはノーパターン。

この質問は、私の以前の投稿の一種です：javaでのビジターパターンの実装-これはどのように見えますか？

コードのリファクタリング中に少し混乱しました。ビジターパターン（前の投稿で説明）を複合戦略パターンに変換しようとしています。私はこのようなことをしようとしています：

ここで、次のようなルールを定義します。

これで、検証する2つの異なるタイプのオブジェクトを作成できます。これらの2つは完全に異なる可能性があります。あるストアがありValidatable、次にあるストアがScheduleあるとしValidatableます。さて、次のようなコンポジットを作成するとします。

enumどのチェックセットがどこに行くかを定義するを定義します...

そして最後に、私はそれを次のように使用します：

デザインに欠陥があるのが不思議です。Ruleインターフェースがを期待しているという考えは好きではありませんValidatable。これをどのように改善するか提案していただけますか？

あなたの助けに感謝。

私はパターンを設計するのが初めてなので、これはおそらく初心者の質問ですが、テンプレートメソッドと戦略 DP を見ていましたが、それらは非常に似ているようです。定義を読んだり、UML を調べたり、コード例をチェックしたりできますが、私には、Strategy パターンは Template Method パターンを使用しているだけのように見えますが、たまたまそれをオブジェクト (つまり、構成) に渡しているだけです。

さらに言えば、テンプレート メソッドは基本的な OO 継承にすぎないようです。

それらの違いのいくつかの重要な側面が欠けていますか? テンプレートメソッドについて、基本的な継承以上のものを見逃していますか?

注: これに関する以前の投稿 ( 672083 ) がありますが、いつ使用するかについて詳しく説明されています。

私はデザインパターンの初心者です。

開発チームのさまざまなメンバーが行った開発作業を追跡する C# アプリケーション (つまり、プロジェクト トラッカー) を開発しているとします。

私は戦略パターンに触発されようとしています。

したがって、次のようにクラスとインターフェイスを設計しています。

このデザインを改善するにはどうすればよいですか?

ここでの目的は、UIを更新することです。私は通常クライアントでこれを行いますが、このアプリケーションはコードビハインドを使用します。とにかく私の質問は、elseステートメントの場合はこれらをクリーンアップしようとしていることであり、戦略パターンが適切である可能性があると思いました。私は私のためにすべてを行う必要はありませんが、あなたが私に始めるためのいくつかの指針を与えることができれば。最初にインターフェースを作成してから、各戦略でインターフェースを実装しますか？ジェネリックはここで役に立ちますか？インターフェイスにはどのような種類のメソッドを含める必要がありますか？私を動かすために何かがあれば非常にありがたいです。

ありがとう、〜ck

私が開発しているアプリケーションでは、状況に直面しています。このための設計パターンがあるかどうか知りたいです。以下の通りです

1. ユーザーは、プロセスのさまざまなアルゴリズムを使用して Web インターフェイスに表示されます
2. ユーザーの選択はデータベースに保存されます。
3. ここで、アプリケーションは、選択したアルゴリズムに応じて異なる方法で計算を実行する必要があります。

これを実装するための良い戦略は何ですか? 今、私たちがやっていることは -

1. コード内のすべてのアルゴリズム タイプと対応するクラス名を含む参照 DB テーブルを用意します (たとえば、クイック ソート アルゴリズムの場合、QuickSort を格納します)。これは、新しいアルゴリズムが登場するたびに手動で更新する必要があります

2. コードでは、アルゴリズム タイプを取得し、リフレクションを使用して適切なアルゴリズム タイプをインスタンス化します。C# では、以下のようなコードを使用します

   System.Reflection.Assembly 型 = System.Reflection.Assembly.LoadFile(System.Reflection.Assembly.GetExecutingAssembly().Location.ToString());
   foreach (type t in types) if (t.Name==classname) createinstanceof(t) //classnames は、DB の参照テーブルからロードされるすべてのクラス タイプのリストです。

私の直感では、これは非常に標準的な問題のように見えるため、これを行うためのより簡単でより良い方法があるはずです。私は戦略パターンを知っていますが、私が望むのは、単純化して、できれば手動タスクを削除することです。

なぜ戦略ではなくアダプターと呼ばれるのですか?

2つのデータ構造クラスがあります（これは私のコードの簡略化されたバージョンです）

• 動物：「intAge」というプロパティが1つあります
• 人物：「DateTimeBirthday」というプロパティが1つあります</ li>

私が達成しようとしているのは、すべての異なるデータ構造クラスに共通する「アップロード」（データベースに永続化）をコンパイルすることです。したがって、主に私の目標は、次のような小さなUploadメソッドを使用することです。

しかし、問題は、populatorが異なるタイプのオブジェクトインスタンスを返すことです。これらには共通のプロパティがないため、カプセル化しようとしています。（以下のコードのIDataPopulator.TResult Populate（string data））

これを回避する方法はありますか？または、戦略パターンはこの種のシナリオに適合しませんか？

これが私が使ってきたコードです