Come abbreviare la dichiarazione del caso da hades? [duplicare]

Il mio consiglio sarebbe di lasciare bene da solo.

Un interruttore è il meccanismo di ramificazione più efficiente possibile, soprattutto quando è accoppiato con un enum.

Qualunque altra cosa produrrà un successo in termini di prestazioni.

Potrebbe valere la pena di scomporre il codice inline in metodi separati per la leggibilità (il compilatore JIT probabilmente si limiterà a ricollegarli di nuovo, quindi niente overhead).

Personalmente non trovo nulla di sbagliato con due o tre metodi di linea, se questo aiuta la leggibilità.

Inoltre, per motivi di leggibilità, potresti considerare di mettere ogni caso su una singola riga in questo modo: ----

switch {humungous_ENUM) {
    case OPTION_1:      exOption_1();            break;
    case OPTION_2:      exOption_2();            break;
     ......
    case OPTION_99:     exOption_99();           break;
    default:            exOption_error();   
}

Questo proviene da una prospettiva C #, ma quello che farei in questo caso è il seguente:

1. Rifatta tutti i "piccoli bit di codice" in metodi separati.
2. Crea un dizionario che è inserito nell'enumerazione e che contiene un delegato di azione (un delegato che restituisce void ed è senza parametri).
3. Crea un metodo che aggiunge ciascuna coppia enum / delgate al dizionario.
4. Utilizza il dizionario come ricerca per eseguire il codice corretto.

E per gli utenti più avanzati:

• Crea un attributo che prende il valore enum come parametro. Al caricamento, riflettere sull'assieme e aggiungere automaticamente ogni coppia di valori / metodi di enumerazione al dizionario (ciò salverà su tutto il codice "aggiunta al dizionario").

Dici che ogni case nella tua grande switch corrisponde a un metodo API pubblico (anche pubblicato?). Da ciò deduco che le chiamate a quei metodi dell'API sono, in realtà, chiamate ad alcune funzioni comuni con il parametro enum corrispondente. Presumo anche che tu abbia la possibilità di cambiare questa interfaccia API pubblica.

Non ha importanza la dimensione di questi metodi; se sono indipendenti, dovrebbero essere isolati in funzioni pubbliche separate. Questo è vero per i metodi che implementano un comportamento non correlato ed è ortogonale alla loro implementazione in sé (quelle classi che hai menzionato per avere tutte le cose complicate). Una cosa diversa è avere diversi metodi con un comportamento simile, nel qual caso potrebbe essere aggiunto un singolo metodo parametrico. La principale linea guida per ridurre la quantità di funzioni pubbliche eviterebbe la duplicità del comportamento su di loro.

Ultimo, ma non meno importante, prova a raggruppare i metodi semanticamente correlati (magari usando le classi statiche), in modo da introdurre qualche struttura nell'array di funzioni altrimenti piatto.