Cosa può andare storto nel comporre un nome di metodo da una stringa?

In fase di esecuzione, la cosa peggiore che potrebbe probabilmente accadere è che il metodo non esiste, quindi ottieni una sorta di errore in fase di esecuzione che dice ERROR: method: 'switchToFoo' could not be found in context blah blah blah...

Non sono sicuro che questo tipo di codice possa essere vulnerabile agli attacchi di iniezione. Da dove viene il valore per filter ?

Un problema più grande potrebbe essere che qualsiasi strumento di sviluppo che stai usando non sarà in grado di lavorare con questo. Ad esempio, se vuoi che l'IDE cerchi tutti i luoghi in cui viene chiamato switchToFoo , non sarà possibile trovare quelli chiamati dallo snippet che hai mostrato sopra. O se si desidera refactoring switchToFoo a switchToFou , è necessario modificare il nome del metodo e quindi modificare il codice che passa il valore per filter . Tu saprai tutto su questo, ma questo genere di cose di solito fa scattare gli sviluppatori che sono nuovi al progetto.

What can go wrong with composing a method name out of a string?

Se myObject[filterMethod]() non esiste, potresti bloccare la tua applicazione.

Se la tua applicazione fa parte dei controlli di sicurezza per il controllo antincendio di missili nucleari, potresti potenzialmente disabilitare i controlli di sicurezza critici.

Se altri software per i controlli non tengono conto di questo incidente, puoi permettere a chiunque di sparare missili zebrati.

Se qualcuno sta passando una brutta giornata, potrebbe decidere di provare a lanciare i missili e si sorprenderà che lancino.

Se lanciano i missili, potresti iniziare una guerra nucleare.

Se inizia una guerra nucleare, potresti mettere fine alla civiltà come la conosciamo.

PER L'AMORE DEI BAMBINI CONTROLLA LE COSE ESISTENTI PRIMA DI ACCEDERLI!

Il più grande rischio è provare ad accedere a qualcosa che non esiste all'interno della struttura dell'array. Nel peggiore dei casi, ciò causerà il crash dell'applicazione. Nel migliore dei casi, non ci sarebbe alcuna operazione percepita in corso.

Se hai avvolto quella logica con alcuni controlli di guardia per assicurarti di non accedere a qualcosa che non c'era, sarebbe un po 'più robusto. Potresti anche prendere in considerazione l'aggiunta della registrazione per le richieste errate che riescono ancora a entrare. Con le informazioni del registro, potresti cercare i problemi dopo il fatto.

È una forma di riflessione, che ha i suoi usi in applicazioni generate dinamicamente (come un generatore GUI per esempio) o plug-in, ma dovrebbe essere una questione di ultima istanza al di fuori di questi contesti.

Oltre alle ottime ragioni indicate in altre risposte, è un segno che la gerarchia delle classi probabilmente necessita di refactoring. Fare così molto probabilmente renderà molto più facile ragionare su tutto il tuo codice. Per un esempio refactored:

switchToFilter = function(filterName){
    var filter = filters[filterName];
    filter.switch();
}

Ciò ti consente di utilizzare l'ereditarietà per evitare la duplicazione delle funzioni dello switch e molto probabilmente ha un effetto collaterale di fornire un luogo comodo in cui inserire altri comportamenti specifici del filtro.

• Se filter proviene da una fonte esterna come un utente, hai una potenziale fonte di errori non previsti, probabilmente un problema di sicurezza a seconda del contenuto di myobject .
• La ricerca avviene in fase di runtime in modo da non ottenere i tipici vantaggi del controllo dei tipi (esistenza, firma della firma che corrisponde alla firma della funzione, ecc.)

Detto questo, io uso tabelle di distribuzione molto simili a quelle che hai nel tuo esempio. Sono utili in casi particolari. La chiave è capire quali sono i costi (e i rischi) e accertarsi che non ne valutino i benefici.

Se la stringa proviene da una fonte non sicura (input dell'utente, ecc.) è assolutamente, totalmente inaccettabile. Hai volontariamente aggiunto una vulnerabilità di codice in codice al tuo codice.

Puoi scrivere un codice che mapperà una lista di nomi di funzioni note a funzioni conosciute, dove hai verificato che ognuna di queste funzioni può essere chiamata senza effetti collaterali negativi.