Utilizzo di action array rispetto a Switch Case [closed]

IMHO il primo è nella maggior parte dei casi preferibile. Innanzitutto, in C # puoi riscrivere l'inizializzazione molto più breve di

    Action[] array = new[]{one, two, thre, four, five, six, seven,eight,nine};

Ma il vero vantaggio arriva quando devi modificare le tue azioni in seguito, ad esempio, introducendo un argomento aggiuntivo. Devi quindi modificare solo questa linea

    array[buttons.Count - 1](myArgument);

La variante switch ha invece bisogno di modifiche nei 9 posti:

switch(buttons.count){
case 1: one(myArgument); break;
case 2: two(myArgument); break;
...

Questo perché la variante switch non segue il principio "Do not Repeat Yourself" (DRY). Immagina cosa succede quando non hai solo 9 azioni, ma 50, o devi introdurre più argomenti, o elaborare un codice di ritorno dall'azione / funzione.

E non preoccuparti troppo delle prestazioni - nella maggior parte dei casi reali la differenza di prestazioni è trascurabile. E quando non lo è, dovrai provare misurare se una sostituzione con un'istruzione switch porta davvero il guadagno di prestazioni necessario.

Bene, ci sono molti argomenti in un modo o nell'altro.

Ma la cosa più importante da realizzare: non ha importanza (in questo caso).

• Per quanto riguarda le prestazioni, il disegno (e il successivo rendering di esso) richiederà un ordine di grandezza più lungo dell'invocazione delle funzioni di disegno corrette.
• Per quanto riguarda la complessità, il codice di disegno molto probabilmente supererà in modo schiacciante il problema dell'invocazione. Il fatto che tu abbia bisogno di nove diverse funzioni di disegno lo rende abbastanza chiaro.

Se si è realmente interessati a questo, la cosa giusta da fare è mettere in blackbox la decisione in una classe separata, dove entra un conteggio dei pulsanti e viene fuori una funzione di disegno. Quindi nessun altro codice dipende da come questo è stato realizzato e puoi cambiarlo ogni volta che ne hai una ragione.

Naturalmente ci sono effetti pro e contro; se non ci fosse stato, la comunità li avrebbe già scoperti da molto tempo e tutti avrebbero accettato di fare sempre l'uno e mai l'altro.

Un'istruzione switch va bene se le cose che passi hanno solo un comportamento. Un pulsante fa qualcosa quando viene cliccato, quindi sembra appropriato. Ma non appena la variabile che stai passando ha più di un comportamento, avrai bisogno di una seconda istruzione switch che elenca esattamente gli stessi casi. Questa è una violazione di DRY e peggiorerà con ogni altra cosa aggiunta alla classe. E siamo onesti: quando è stata l'ultima volta che hai visto una classe affermata ottenere un meno complesso?

Un array di oggetti che inviano tutti gli stessi messaggi evita questo problema. Può essere o meno meno efficiente di un switch compilato in una tabella di salto. Se lo è, la differenza può o non può valere la pena di compromettere altri principi. Se lo è, potrebbe essere o non essere una buona idea se li comprometti ora, considerando che il sistema si evolverà ulteriormente e il piccolo compromesso di oggi potrebbe diventare un enorme mal di testa per gli anni a venire.

Questo è il motivo per cui solo tu sai se scegliere un'opzione rispetto all'altra: perché i dettagli dell'applicazione tua probabilmente superano le pressioni generali che possiamo elencare per te.

(È un po 'come il pregiudizio: quando tutto ciò che sai di un'applicazione web è che è stato scritto da volontari in PHP, va bene presumere che sia probabilmente dal lato meno sicuro rispetto a quello usato da una grande banca Dopotutto, molte di queste app sono di fatto insicure, ma se si hanno esempi concreti di entrambe le app Web, osservare i particolari di entrambe le istanze è virtualmente sempre più intelligente che basarsi su massime generali, cioè pregiudizi. )