複数のスイッチケースを持つアプリケーションをリファクタリングするにはどうすればよいですか？

整数を入力として受け取り、その入力に基づいて異なるクラスの静的メソッドを呼び出すアプリケーションがあります。新しい番号が追加されるたびに、別のケースを追加して、異なるクラスの異なる静的メソッドを呼び出す必要があります。現在、スイッチには50のケースがあり、別のケースを追加する必要があるたびに、震えます。これを行うより良い方法はありますか？

私はいくつか考えて、このアイデアを思いつきました。私は戦略パターンを使います。スイッチケースを持つ代わりに、キーが入力整数である戦略オブジェクトのマップがあります。メソッドが呼び出されると、オブジェクトが検索され、オブジェクトのジェネリックメソッドが呼び出されます。このようにして、switch case構文の使用を回避できます。

どう思いますか？

現在、スイッチには50のケースがあり、別のケースを追加する必要があるたびに、震えます。

私はポリモーフィズムが大好きです。SOLIDが大好きです。純粋なオブジェクト指向プログラミングが大好きです。彼らが独断的に適用されるので、私はこれらが悪い担当者を与えられるのを見たくありません。

戦略にリファクタリングするための適切なケースを作成していません。ちなみにリファクタリングには名前があります。これは、「条件付きをポリモーフィズムに置き換える」と呼ばれます。

私はc2.comからいくつかの適切なアドバイスを見つけました：

同じまたは非常に類似した条件テストが頻繁に繰り返される場合にのみ意味があります。単純でめったに繰り返されないテストの場合、単純な条件を複数のクラス定義の冗長性で置き換え、条件付きで必要なアクティビティを実際に必要とするコードからこれまでのところすべてを移動すると、コード難読化の教科書の例が得られます。独断的な純度よりも明快さを優先します。-DanMuller

50ケースのスイッチがあり、50個のオブジェクトを作成することもできます。ああ、50行のオブジェクト構築コード。これは進歩していません。何故なの？このリファクタリングは、数を50から減らすためには何もしません。同じ入力で別のどこかに別のswitchステートメントを作成する必要がある場合は、このリファクタリングを使用します。100を50に戻すため、このリファクタリングが役立ちます。

あなたが持っている唯一のものであるようにあなたが「スイッチ」に言及している限り、私はこれをお勧めしません。今リファクタリングから得られる唯一の利点は、一部のgoofballが50ケーススイッチをコピーして貼り付ける可能性が減ることです。

私がお勧めするのは、これらの50のケースをよく検討して、除外できる共通点を探すことです。50って意味？本当に？あなたは本当に多くのケースが必要ですか？ここで多くのことをしようとしているのかもしれません。

いくつかのコード行が次のようになっているコードのいくつかの関数で初期化される戦略オブジェクトのみのマップ

     myMap.Add(1,new Strategy1());
     myMap.Add(2,new Strategy2());
     myMap.Add(3,new Strategy3());

あなたとあなたの同僚は、より均一な方法で別々のクラスで呼び出される関数/戦略を実装する必要があります（戦略オブジェクトはすべて同じインターフェースを実装する必要があるため）。そのようなコードは多くの場合よりも少し包括的です

     case 1:
          MyClass1.Doit1(someParameters);
          break;
     case 2:
          MyClass2.Doit2(someParameters);
          break;
     case 3:
          MyClass3.Doit3(someParameters);
          break;

ただし、新しい番号を追加する必要がある場合でも、このコードファイルを編集する負担から解放されません。このアプローチの本当の利点は別のものです。

• マップの初期化は、特定の番号に関連付けられた関数を実際に呼び出すディスパッチコードから分離され、後者には50回の繰り返しが含まれていないため、のようになりmyMap[number].DoIt(someParameters)ます。そのため、このディスパッチコードは、新しい番号が到着するたびに触れる必要がなく、Open-Closedの原則に従って実装できます。さらに、ディスパッチコード自体を拡張する必要がある場合、50か所を変更する必要はなく、1か所だけを変更する必要があります。

• マップのコンテンツは実行時に決定されるのに対し（スイッチコンストラクトのコンテンツはコンパイル前に決定されます）、これにより、初期化ロジックをより柔軟または拡張可能にする機会が得られます。

したがって、はい、いくつかの利点があります。これは確かに、SOLIDコードを増やすためのステップです。しかし、それがリファクタリングに見合うものである場合、それはあなた自身またはあなたのチームが自分で決定しなければならないことです。ディスパッチコードの変更、初期化ロジックの変更を予期してswitchおらず、の可読性が実際の問題ではない場合、リファクタリングはそれほど重要ではない可能性があります。

@DocBrownの回答で概説されている戦略に強く賛成です。

答えの改善を提案します。

呼び出し

 myMap.Add(1,new Strategy1());
 myMap.Add(2,new Strategy2());
 myMap.Add(3,new Strategy3());

配布できます。同じファイルに戻って別の戦略を追加する必要はありません。これは、Open-Closedの原則にさらに準拠しています。

Strategy1ファイルStrategy1.cppに実装するとします。次のコードブロックを含めることができます。

namespace Strategy1_Impl
{
   struct Initializer
   {
      Initializer()
      {
         getMap().Add(1, new Strategy1());
      }
   };
}
using namespace Strategy1_Impl;

static Initializer initializer;

すべてのStategyN.cppファイルで同じコードを繰り返すことができます。ご覧のとおり、これはコードの繰り返しになります。コードの重複を減らすために、すべてのStrategyクラスがアクセスできるファイルに入れることができるテンプレートを使用できます。

namespace StrategyHelper
{
   template <int N, typename StrategyType> struct Initializer
   {
      Initializer()
      {
         getMap().Add(N, new StrategyType());
      }
   };
}

その後、Strategy1.cppで使用する必要があるのは次のものだけです。

static StrategyHelper::Initializer<1, Strategy1> initializer;

StrategyN.cppの対応する行は次のとおりです。

static StrategyHelper::Initializer<N, StrategyN> initializer;

具体的なStrategyクラスのクラステンプレートを使用することで、テンプレートの使用を別のレベルに引き上げることができます。

class Strategy { ... };

template <int N> class ConcreteStrategy;

そして、の代わりにStrategy1を使用しますConcreteStrategy<1>。

template <> class ConcreteStrategy<1> : public Strategy { ... };

ヘルパークラスを変更して、Strategysを次のように登録します。

namespace StrategyHelper
{
   template <int N> struct Initializer
   {
      Initializer()
      {
         getMap().Add(N, new ConcreteStrategy<N>());
      }
   };
}

Strateg1.cppのコードを次のように変更します。

static StrategyHelper::Initializer<1> initializer;

StrategN.cppのコードを次のように変更します。

static StrategyHelper::Initializer<N> initializer;