L'incapsulamento del codice Javascript negli oggetti influisce sulle prestazioni?

Question

Mi chiedo se sia più o meno efficace incapsulare il corpo principale del codice JavaScript in un oggetto? In questo modo l'intero ambito del tuo programma sarebbe separato da altri ambiti come la finestra.

Per esempio, se ho avuto il seguente codice in un file JavaScript:

/* My main code body. */ 
var somevar1=undefined; 
var somevar2=undefined; 
var somevarN=undefined; 

function somefunction(){}; 

function initialize(){/* Initializes the program. */}; 
/* End main code body. */ 

ho potuto invece incapsulare il corpo codice principale in un oggetto:

/* Encapsulating object. */ 
var application={}; 
application.somevar1=undefined; 
application.somevar2=undefined; 
application.somevarN=undefined; 

application.somefunction=function(){}; 

application.initialize=function(){/* Initializes the program. */}; 

La mia logica è che, poiché JavaScript ricerca tutte le variabili in un ambito finché non viene trovato quello giusto, mantenendo le funzioni e le variabili specifiche dell'applicazione nel proprio ambito aumenterebbe l'efficienza, specialmente se ci fossero un sacco di funzioni e variabili.

La mia unica preoccupazione è che questa è una cattiva pratica o che forse questo aumenterebbe il tempo di ricerca di variabili e funzioni all'interno del nuovo ambito di "applicazione". Se questa è una pratica sbagliata o completamente inutile, per favore fatemelo sapere! Grazie!

Answer 1

Non ho idea di quali siano le implicazioni sulle prestazioni (ho il sospetto che siano trascurabili in entrambi i casi, ma se sei davvero preoccupato, testarlo), ma è prassi comune in JavaScript mantenere frammenti di codice nella loro proprio ambito, piuttosto che avere tutto nella portata globale.

Il vantaggio principale è la riduzione del rischio di sovrascrittura accidentale delle variabili nell'ambito globale e la semplificazione della denominazione (ad esempio, è disponibile window.application.initialize anziché, ad esempio, window.initialize_application).

Anziché l'implementazione sopra riportata, è possibile utilizzare le funzioni di auto-chiamata per creare un'area di ambito solo per un bit di codice. Questo è noto come the module pattern.

Questo ha il vantaggio di permettere di creare le variabili “privati” che sono accessibili solo all'interno del modulo, e quindi non sono accessibili da altro codice in esecuzione nello stesso oggetto globale:

/* Encapsulating object. */ 
var application=(function() { 
    var someprivatevar = null// This can't be accessed by code running outside of this function 
     , someprivatefunction = function() { someprivatevar = someprivatevar || new Date(); }; 

    return { 
     somevar1: undefined 
     , somevar2: undefined 
     , somevarN: undefined 
     , somefunction: function(){} 
     , getInitialized: function() { return someprivatevar; } 
     , initialize: function(){/* Initializes the program. */ someprivatefunction(); } 
    }; 

})(); 

application.initialize(); 
application.getInitialized();// Will always tell you when application was initialized 

Answer 2

I renditi conto che hai fatto una domanda sì o no. Tuttavia, la mia risposta è non preoccuparti, e per confermarlo, voglio pubblicare una citazione da Eloquent Javascript, di Marijn Haverbeke.

Il dilemma della velocità rispetto all'eleganza è interessante. È possibile vedere come una sorta di continuum tra la cordialità umana e facilità d'uso. Quasi tutti i programmi possono essere resi più veloci rendendo lo più grande e più contorto. Il programmatore deve decidere su un bilancia appropriato .... La regola di base, che è stata ripetuta da molti programmatori e con che concordo pienamente, è di non preoccuparsi dell'efficienza fino allo si sa per certo che il programma è troppo lento. Se lo è, scopri quali parti occupano più tempo e inizia a scambiare eleganza per l'efficienza in quelle parti.

Answer 3

Avere un codice di facile lettura è la chiave del mio problema qui, quindi seguirò l'approccio modulare anche se esiste una catena di ricerca leggermente più lunga per variabili e funzioni. Entrambi i metodi sembrano avere pro e contro così com'è.

Da una parte, si dispone dell'ambito globale che contiene numerose variabili dall'inizio. Se si inserisce tutto il codice all'interno dell'ambito globale, l'elenco di variabili incluse in tale ambito includerà le proprie e anche variabili come innerWidth e innerHeight. L'elenco da cercare quando si fa riferimento alle variabili sarà più lungo, ma credo che sia una quantità così piccola di spese generali di cui è ridicolo preoccuparsi.

D'altra parte, è possibile aggiungere un solo oggetto all'ambito globale che contiene tutte le variabili con cui si desidera lavorare. All'interno di questo ambito, è possibile fare riferimento a queste variabili facilmente ed evitare la ricerca attraverso variabili globali come innerWidth e innerHeight. Il problema è che quando si accede alle variabili incapsulate dall'ambito globale si avrebbe una catena di ricerca più lunga come: globalscope.customscope.myvar invece di globalscope.myvar o solo myvar.

Quando lo guardo in questo modo, sembra una domanda molto banale. Forse il modo migliore per farlo è incapsulare le cose che vanno insieme solo per il codice decluttering e concentrarsi sulla leggibilità piuttosto che avere un pasticcio di codice illeggibile che è solo leggermente più efficiente.