Quale di questi è il modo migliore per strutturare le funzioni in JavaScript?

In questo caso - una semplice funzione che accetta un solo argomento e può essere gestita con una semplice dichiarazione switch - dovresti farlo. Non ottieni nulla dalla suddivisione in funzioni separate, ad eccezione del codice aggiuntivo da mantenere. Una funzione dovrebbe eseguire una operazione in modo chiaro e succintamente - una semplice istruzione switch come la tua certamente non infrange quella regola.

Rompendo la tua logica in funzioni specifiche per i diversi colori, indebolisci anche il tuo design complicando la logica del programma in altri luoghi: quando cambi i colori, dovrai arbitrariamente sapere (mai bene) o includere la logica per determinare quale funzione è necessario chiamare quel punto. Con la tua funzione parametrizzata sarà molto più facile chiamare la funzione in fase di esecuzione e manipolare dinamicamente i colori senza dover sapere quale particolare funzione devi chiamare.

Fai una "analisi costi / benefici" quando progetti le tue funzioni: questa funzione sta diventando troppo lunga e complessa? Sta provando a fare troppe cose contemporaneamente? Esprime correttamente l'idea che vuoi implementare? Il prossimo sviluppatore che si occupa di questo codice lo capirà facilmente? Essere in grado di modificarlo facilmente? Usalo in altri situtations? La tua funzione corrente con switch soddisfa tutti questi criteri (tranne l'ultimo - più su quello sotto.)

Tuttavia, ciò che merita qualche considerazione è la tua prima riga:

 this.removeColour(); 

Capisco che è necessario rimuovere il vecchio colore prima di impostare quello nuovo ed è conveniente racchiudere la chiamata in removeColour insieme all'impostazione del nuovo colore. Ma questo potrebbe essere un esempio di ciò che chiamiamo "raggruppamento" - combinando diverse operazioni non necessariamente correlate in un'unica funzione.

Nel tuo caso, questo è probabilmente un non-problema - tu devi cancellare il vecchio colore - AFAIK (non sono un ragazzo JavaScript) - prima di impostare quello nuovo, quindi removeColour appartiene in questa funzione - è un elemento essenziale dell'operazione changeColour . Quindi il mio punto qui è semplicemente didattico. Ma è fin troppo comune trovare il codice che è colpevole di "raggruppare" in questo modo, quando non è così: semplicemente unire un gruppo di operazioni non correlate insieme per comodità.

Tale pratica porta a un codice difficile da mantenere, non robusto: arriverà il momento in cui è necessario eseguire solo una o alcune delle operazioni non correlate, e non tutte. Quando ciò accade, dovrai duplicare il codice o modificare il codice in bundle e dividerlo in funzioni separate: lavoro extra / tempo / denaro. Questo è uno (di molti) tipi di scenari in cui dovresti pensare a scrivere funzioni separate per gestire diverse operazioni.

Qualcos'altro da considerare è questa linea:

this.colour('blue');

Forse un altro esempio di "raggruppamento": impostando il colore di this all'interno di questa funzione, ne hai ristretto l'ambito e l'usabilità: ora la funzione funziona solo per this ma non per altri widget. Potresti prendere in considerazione il fatto che la funzione restituisca una stringa con il nome di colore.

return 'blue'...

E chiedi al chiamante di utilizzare il risultato per impostare this.colour (colorName):

colorName = changeColor(blue);
this.colour(colorName):

Quindi tu (o qualcun altro) potresti anche scrivere:

colorName = changeColor(red);
aWidget.color(colorName):

etc ..

Se lo fai, oltre a dover modificare la funzione per restituire un string e gestire l'operazione removeColor , dovresti probabilmente cambiare il nome della funzione in GetColorName(colour) - perché in realtà non stai cambiando il colore nella funzione, ma semplicemente ottenendo la rappresentazione della stringa del colore desiderato. Un nome di funzione dovrebbe descrivere chiaramente cosa sta facendo la funzione.

Sebbene, in una certa misura, la scelta di quanto granulare rendere le definizioni delle funzioni abbia a che fare con la percezione della leggibilità, ciò dipende anche dalla manutenibilità. Se si finisce con un codebase che ha un lotto di funzioni che fanno tutte una cosa molto simile (nel tuo esempio, l'ultimo livello di granularità), allora se devi cambiare il modo in cui il Funzionalità ripetute funziona devi andare in ognuna delle funzioni simili per fare lo stesso cambiamento e potresti perdere uno.

Se puoi mettere questa funzionalità simile in una funzione breve leggibile, allora sarei tentato di farlo. Assicurati che sia breve e (come un esempio arbitrario) adatto a 50 linee os così e codifica solo una idea principale.

Di solito, vuoi avere esattamente un posto dove viene eseguito il tuo codice reale, che è il tuo primo esempio. Tuttavia, a volte si desidera un codice più semplice per leggere e scrivere. Nel tuo caso, potresti voler fare qualcosa del genere:

function changeColour(colour) {
  this.removeColour();  
  switch(colour){
    case "red":
      this.colour('red');
    break;
    case "blue":
     this.colour('blue');
   break;
 }
}
function makeRed() {
  changeColour("red");
}
function makeBlue() {
  changeColour("blue");
}

In questo modo, makeRed() e makeBlue() hanno entrambi risultati garantiti e sono facili da leggere e scrivere. Inoltre, se c'è un bug nel tuo codice, è probabile che lo schiacci cercando solo changeColour(colour) , il che fa risparmiare tempo e aiuta a rendere il tuo codice privo di errori.

Usiamo questa stessa pratica con linguaggi come Java, che consentono solo un numero fisso di parametri per metodo, al fine di rendere diversi metodi con parametri diversi che fanno la stessa cosa. Per ulteriori informazioni, consulta link , che fa un buon lavoro nel delineare questa pratica.