これにはどのデザインパターンを使用しますか？

Question

私は、タイプに基づいて1回または複数回（ループで）実行する必要のあるロジックを持っています。戦略パターンはここで理にかなっていますか？本質的には、

Answer 1

通常、戦略パターンはアルゴリズムのファミリを定義し、それぞれをカプセル化し、それらを交換可能にします。ストラテジーは、アルゴリズムを使用するクライアントとは独立してアルゴリズムを変えることができます。

私は価値があなたがProcessReportの振る舞いをカプセル化したい場合は自分で IProcessReport.Process(userId)を呼び出すことができますように、私はこの振る舞いを表すインターフェイスを作成し、抽象化

の別の層を追加している任意の複雑なアルゴリズムが表示されない

ループ

Answer 2

あなたのコードは、このように単純化することができます。もちろん、

if (type == 1) 
    SendFullReport(); 
else if (type == 2) 
    for (int i = 0; i < numUsers; i++) 
     GetReportFragment(userId); 

は、あなたがSendFullReport()とGetReportFragment(string userId)メソッドを実装する必要があります。

複雑なデザインパターンをこの文脈で使用することには意味がありません。

Answer 3

type変数のセマンティクスに応じて、多態性を使用すると意味があります。

オーバーヘッド（2つのブランチしかありません）がある場合、if() ... else if() ... else if() ...またはswitch() { case: ... }のような構造が表示されるたびに、いくつの条件付きブランチが存在するのでしょうか？将来新しいものが登場する可能性はありますか？

これらの質問の回答に応じて、Replace Conditional with Polymorphismリファクタリングを行うことがあります。

Answer 4

これは単なる例ですか、それとも実際のサイズですか？つまり、2つのタイプがある場合、使用するのに最適なパターンはそれを単純に保つことです。

複数のタイプがある場合は、その中で戦略を取るか、実行するコードを持つ辞書タイプの委任/コマンドを使用できます。

Answer 5

異なる動作を区別するために「タイプコード」を使用しているので、replacing it with subclasses (polymorphism)から開始できます。これは通常、タイプコードベースの分岐があるときに行う最初の処理です。

しかし、簡単な問題では、これは過度の可能性があります。どのようなあなたのコードでより多くの不快なのは、次のとおりです。

• マジックナンバーあなたのタイプのためのの使用：あなたは、少なくとも特定を示すために空のパラメータ（""）を通過可読性
• を改善するために、列挙型にそれらを変更する必要がありますあなたが指定するIDを持っていない場合、少なくとも "完全なレポート"のための別個のメソッドを作成する

Answer 6

現在の機能の単純さにもかかわらず戦略パターンが正しい解決策であるように感じます。一般的に、私はif文を避け、自分のコードを霧化しようとします。 Grooのコード「臭い」の観察も私のものです。多態性（戦略）は過剰なものと思われるかもしれませんが、私はむしろ空である文字列パラメータや数値に基づいて関数の動作を変更しようとするよりも、やや抽象的な解決策になります。