Come refactificare un'applicazione con più casi di switch?

Ho un'applicazione che accetta un intero come input e basato sull'input chiama metodi statici di diverse classi. Ogni volta che viene aggiunto un nuovo numero, è necessario aggiungere un altro caso e chiamare un metodo statico diverso di una classe diversa. Ora ci sono 50 casi nello switch e ogni volta che devo aggiungere un altro caso, rabbrividisco. C'è un modo migliore per farlo.

Ho pensato e mi è venuta questa idea. Uso il modello di strategia. Invece di avere una custodia, ho una mappa di oggetti di strategia con la chiave come intero di input. Una volta invocato il metodo, cercherà l'oggetto e chiamerà il metodo generico per l'oggetto. In questo modo posso evitare di usare il costrutto switch case.

Cosa ne pensi?

Ora ci sono 50 casi nello switch e ogni volta che devo aggiungere un altro caso, rabbrividisco.

Adoro il polimorfismo. Adoro il SOLID. Adoro la pura programmazione orientata agli oggetti. Odio vederli dare una cattiva reputazione perché vengono applicati dogmaticamente.

Non hai fatto un buon caso per il refactoring alla strategia. A proposito, il refactoring ha un nome. Si chiama Sostituisci condizionale con polimorfismo .

Ho trovato alcuni consigli pertinenti per te da c2.com :

Ha davvero senso solo se si ripetono spesso test condizionali uguali o molto simili. Per test semplici, ripetuti di rado, la sostituzione di un semplice condizionale con la verbosità di più definizioni di classe e il probabile spostamento di tutto ciò lontano dal codice che richiede effettivamente l'attività richiesta condizionatamente, si tradurrebbe in un esempio da manuale di offuscamento del codice. Preferisce la chiarezza sulla purezza dogmatica. - DanMuller

Hai un interruttore con 50 custodie e la tua alternativa è produrre 50 oggetti. Oh e 50 righe di codice di costruzione dell'oggetto. Questo non è progresso. Perchè no? Perché questo refactoring non fa nulla per ridurre il numero da 50. Si utilizza questo refactoring quando si scopre che è necessario creare un'altra istruzione switch sullo stesso input da qualche altra parte. Questo è quando questo refactoring aiuta perché trasforma 100 in 50.

Finché ti riferisci a "l'interruttore" come se fosse l'unico che hai, non lo consiglio. L'unico vantaggio derivante dal refactoring ora è che riduce le possibilità che alcuni goofball copino e incollino il tuo interruttore a 50 casi.

Quello che raccomando è di esaminare attentamente questi 50 casi per elementi comuni che possono essere presi in considerazione. Intendo 50? Veramente? Sei sicuro di aver bisogno di tanti casi? Potresti provare a fare molto qui.

Una mappa di soli oggetti di strategia, che è inizializzata in alcune funzioni del tuo codice, in cui hai diverse righe di codice simili

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

richiede a te e ai tuoi colleghi di implementare le funzioni / strategie da chiamare in classi separate, in modo più uniforme (poiché i vostri oggetti di strategia dovranno implementare tutti la stessa interfaccia). Tale codice è spesso un po 'più completo di

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

Tuttavia, non ti libererà dall'onere di modificare questo file di codice ogni volta che è necessario aggiungere un nuovo numero. I vantaggi reali di questo approccio sono diversi:

• l'inizializzazione della mappa ora viene separata dal codice di invio che in realtà chiama la funzione associata a un numero specifico e quest'ultimo non contiene più quelle 50 ripetizioni, sembrerà solo myMap[number].DoIt(someParameters). Pertanto, non è necessario toccare questo codice di invio ogni volta che arriva un nuovo numero e può essere implementato secondo il principio Open-Closed. Inoltre, quando ottieni requisiti in cui è necessario estendere il codice di spedizione stesso, non dovrai più cambiare 50 posizioni, ma solo una.

• il contenuto della mappa viene determinato in fase di esecuzione (mentre il contenuto del costrutto switch viene determinato prima del tempo di compilazione), in modo da offrire l'opportunità di rendere la logica di inizializzazione più flessibile o estendibile.

Quindi sì, ci sono alcuni vantaggi, e questo è sicuramente un passo verso più codice SOLID. Se ripagare il refactoring, tuttavia, è qualcosa che tu o la tua squadra dovrete decidere da soli. Se non ti aspetti che il codice di invio venga modificato, la logica di inizializzazione venga modificata e la leggibilità del switchnon sia un problema reale, il tuo refactoring potrebbe non essere così importante ora.

Sono fortemente a favore della strategia delineata nella risposta di @DocBrown .

Sto per suggerire un miglioramento alla risposta.

Le chiamate

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

può essere distribuito. Non è necessario tornare allo stesso file per aggiungere un'altra strategia, che aderisce ancora meglio al principio Open-Closed.

Supponi di implementare Strategy1nel file Strategy1.cpp. Puoi avere il seguente blocco di codice in esso.

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

static Initializer initializer;

Puoi ripetere lo stesso codice in ogni file StategyN.cpp. Come puoi vedere, sarà un sacco di codice ripetuto. Per ridurre la duplicazione del codice, è possibile utilizzare un modello che può essere inserito in un file accessibile a tutte le Strategyclassi.

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

Dopodiché, l'unica cosa che devi usare in Strategy1.cpp è:

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

La riga corrispondente in StrategyN.cpp è:

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

È possibile portare l'uso dei modelli a un altro livello utilizzando un modello di classe per le classi di strategia concrete.

class Strategy { ... };

template <int N> class ConcreteStrategy;

E poi, invece di Strategy1, utilizzare ConcreteStrategy<1>.

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

Cambia la classe helper per registrare Strategys in:

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

Modificare il codice in Strateg1.cpp in:

static StrategyHelper::Initializer<1> initializer;

Modificare il codice in StrategN.cpp in:

static StrategyHelper::Initializer<N> initializer;