Come viene chiamato questo pattern JavaScript e perché viene utilizzato?

Sto studiando THREE.js e ho notato un modello in cui le funzioni sono definite in questo modo:

var foo = ( function () {
    var bar = new Bar();

    return function ( ) {
        //actual logic using bar from above.
        //return result;
    };
}());

(Esempio vedere il metodo raycast qui ).

La normale variazione di un tale metodo sarebbe simile a questa:

var foo = function () {
    var bar = new Bar();

    //actual logic.
    //return result;
};

Confrontando la prima versione con la variante normale , la prima sembra differire in quanto:

1. Assegna il risultato di una funzione autoeseguibile.
2. Definisce una variabile locale all'interno di questa funzione.
3. Restituisce la funzione effettiva contenente la logica che utilizza la variabile locale.

Quindi la differenza principale è che nella prima variazione la barra viene assegnata una sola volta, all'inizializzazione, mentre la seconda variazione crea questa variabile temporanea ogni volta che viene chiamata.

La mia ipotesi migliore sul motivo per cui viene utilizzato è che limita il numero di istanze per bar (ce ne sarà solo una) e quindi risparmia il sovraccarico di gestione della memoria.

Le mie domande:

1. Questa ipotesi è corretta?
2. C'è un nome per questo modello?
3. Perché viene utilizzato?

Le tue ipotesi sono quasi corrette. Rivediamo prima quelli.

1. Assegna il ritorno di una funzione autoeseguibile

Questa è chiamata espressione di funzione invocata immediatamente o IIFE

2. Definisce una variabile locale all'interno di questa funzione

Questo è il modo di avere campi oggetto privati ​​in JavaScript poiché non fornisce privatealtrimenti la parola chiave o la funzionalità.

3. Restituisce la funzione effettiva contenente la logica che utilizza la variabile locale.

Ancora una volta, il punto principale è che questa variabile locale è privata .

C'è un nome per questo modello?

Per quanto ne so, puoi chiamare questo pattern Module Pattern . Citando:

Il pattern Module incapsula "privacy", stato e organizzazione utilizzando le chiusure. Fornisce un modo per avvolgere un mix di metodi e variabili pubblici e privati, proteggendo i pezzi dalla fuoriuscita dell'ambito globale e dalla collisione accidentale con l'interfaccia di un altro sviluppatore. Con questo modello, viene restituita solo un'API pubblica, mantenendo privato tutto il resto all'interno della chiusura.

Confrontando questi due esempi, le mie migliori ipotesi sul motivo per cui viene utilizzato il primo sono:

1. Sta implementando il modello di progettazione Singleton.
2. Si può controllare il modo in cui un oggetto di un tipo specifico può essere creato usando il primo esempio. Una stretta corrispondenza con questo punto può essere rappresentata dai metodi di fabbrica statici descritti in Java efficace.
3. È efficiente se hai bisogno dello stesso stato dell'oggetto ogni volta.

Ma se hai solo bisogno dell'oggetto vaniglia ogni volta, allora questo modello probabilmente non aggiungerà alcun valore.

Limita i costi di inizializzazione degli oggetti e garantisce inoltre che tutte le chiamate di funzioni utilizzino lo stesso oggetto. Ciò consente, ad esempio, di memorizzare lo stato nell'oggetto per utilizzarlo in future chiamate.

Sebbene sia possibile che limiti l'utilizzo della memoria, in genere il GC raccoglierà comunque gli oggetti inutilizzati, quindi è probabile che questo modello non sia di grande aiuto.

Questo modello è una forma specifica di chiusura .

Non sono sicuro che questo modello abbia un nome più corretto, ma a me sembra un modulo e il motivo per cui viene utilizzato è sia per incapsulare che per mantenere lo stato.

La chiusura (identificata da una funzione all'interno di una funzione) garantisce che la funzione interna abbia accesso alle variabili all'interno della funzione esterna.

Nell'esempio che hai fornito, la funzione interna viene restituita (e assegnata a foo) eseguendo la funzione esterna, il che significa che tmpObjectcontinua a vivere all'interno della chiusura e più chiamate alla funzione interna foo()opereranno sulla stessa istanza di tmpObject.

La differenza fondamentale tra il tuo codice e il codice Three.js è che nel codice Three.js la variabile tmpObjectviene inizializzata solo una volta e quindi condivisa da ogni invocazione della funzione restituita.

Ciò sarebbe utile per mantenere uno stato tra le chiamate, simile a come le staticvariabili vengono utilizzate nei linguaggi C-like.

tmpObject è una variabile privata visibile solo alla funzione interna.

Cambia l'utilizzo della memoria, ma non è progettato per risparmiare memoria.

Vorrei contribuire a questo interessante thread estendendo il concetto del modello di modulo rivelatore, che garantisce che tutti i metodi e le variabili siano mantenuti privati ​​finché non vengono esplicitamente esposti.

In quest'ultimo caso, il metodo di addizione verrebbe chiamato Calculator.add ();

Nell'esempio fornito, il primo frammento userà la stessa istanza di tmpObject per ogni chiamata alla funzione foo (), dove come nel secondo frammento, tmpObject sarà una nuova istanza ogni volta.

Uno dei motivi per cui il primo snippet potrebbe essere stato utilizzato, è che la variabile tmpObject può essere condivisa tra le chiamate a foo (), senza che il suo valore venga trapelato nell'ambito in cui è dichiarato foo ().

La versione della funzione non eseguita immediatamente del primo frammento sarebbe effettivamente simile a questa:

var tmpObject = new Bar();

function foo(){
    // Use tmpObject.
}

Nota tuttavia che questa versione ha tmpObject nello stesso ambito di foo (), quindi potrebbe essere manipolata in seguito.

Un modo migliore per ottenere la stessa funzionalità sarebbe utilizzare un modulo separato:

Modulo "foo.js":

var tmpObject = new Bar();

module.exports = function foo(){
    // Use tmpObject.
};

Modulo 2:

var foo = require('./foo');

Un confronto tra le prestazioni di un IEF e una funzione di creazione di foo denominata: http://jsperf.com/ief-vs-named-function