2012-05-16 19 views
7

Ho fatto ricerche per trovare uno stile di codifica JavaScript standardizzato per il mio team. La maggior parte delle risorse ora consiglia il modello "Modulo" che coinvolge le chiusure, come questa:Qual è il vantaggio del modello di modulo Javascript?

var Module = function() { 

    someMethod = function() { /* ... */ }; 

    return { 
     someMethod: someMethod 
    }; 

}(); 

e invocano piace Module.someMethod();. Questo approccio sembra funzionare solo con metodi che sarebbero statici in un contesto OOP tradizionale, ad esempio classi di repository per recuperare/salvare dati, livelli di servizio per effettuare richieste esterne e simili. A meno che non mi sia sfuggito qualcosa, il modello del modulo non è destinato a essere utilizzato con classi di dati (si pensi ai DTO) che in genere devono essere trasmessi ai/dai metodi di servizio al codice di colla dell'interfaccia utente.

Un beneficio comune che vedo citato è che si può avere veri metodi privati ​​e campi in Javascript con il modello del modulo, ma questo può essere ottenuto anche insieme essere in grado di avere statici o metodi di istanza con la " classico "stile Javascript simile a questo:

myClass = function(param) { 
    // this is completely public 
    this.publicProperty = 'Foo'; 

    // this is completely private 
    var privateProp = param; 

    // this function can access the private fields 
    // AND can be called publicly; best of both? 
    this.someMethod = function() { 
     return privateProp; 
    }; 

    // this function is private. FOR INTERNAL USE ONLY 
    function privateMethod() { 
     /* ... */ 
    }; 
} 

// this method is static and doesn't require an instance 
myClass.staticMethod = function() { /* ... */ }; 

// this method requires an instance and is the "public API" 
myClass.prototype.instanceMethod = function() { /* ... */ }; 

Quindi immagino che la mia domanda sia ciò che rende il modello di modulo migliore rispetto allo stile tradizionale? È un po 'più pulito, ma sembra essere l'unico beneficio che è immediatamente evidente; infatti, lo stile tradizionale sembra offrire la capacità di fornire un vero incapsulamento (simile ai veri linguaggi OOP come Java o C#) invece di restituire semplicemente una raccolta di metodi solo statici.

C'è qualcosa che mi manca?

+0

Il modello di modulo può essere utilizzato anche per creare prototipi vedere: 'var Module = function() { function Module() {}; Module.prototype.whatever = function() {}; modulo di ritorno }(); ' –

+1

Se si sta definendo un singleton non dovrebbe importare se si utilizzano metodi statici o di istanza. In effetti, preferirei la versione statica da allora non dovrei preoccuparmi di fare un disguido su "questo" quando si usano le funzioni di un callback. – hugomg

risposta

1

Un altro vantaggio che hai dimenticato di menzionare nel modello del modulo è che promuove meno disordine nello spazio dei nomi globale, cioè, a cosa si riferisce la gente quando dice "non inquinare lo spazio dei nomi globale". Certo, puoi farlo nel tuo approccio classico, ma sembra che la creazione di oggetti al di fuori delle funzioni anonime faciliterebbe più facilmente la creazione di quegli oggetti nello spazio dei nomi globale.

In altre parole, il modello di modulo promuove il codice autonomo. Un modulo in genere spinge un oggetto nello spazio dei nomi globale e tutte le interazioni con il modulo passano attraverso questo oggetto. È come un metodo "principale".

Meno spazio nel namespace globale è buono, perché riduce le possibilità di collisioni con altri framework e codice javascript.

1

modello modulo può essere utilizzato per creare prototipi e vedere:

var Module = function() { 
    function Module() {}; 
    Module.prototype.whatever = function() {}; 
    return Module 
}(); 
var m = new Module(); 
m.whatever(); 

Come l'altro poster ha detto che il namespace globale pulita è la ragione per questo. Un altro modo per ottenere questo risultato è utilizzare il pattern AMD, che risolve anche altri problemi come la gestione delle dipendenze. Inoltre avvolge tutto in una sorta di chiusura. Ecco un ottimo Introduction to AMD che sta per Asynchronous Module Definition.

Si consiglia inoltre di leggere JavaScript Patterns in quanto copre accuratamente i motivi dei vari modelli di modulo.

2

Il modello di modulo sopra è inutile. Tutto quello che stai facendo è usare una chiusura per restituire un costruttore con un prototipo. Avresti potuto ottenere lo stesso con:

function Module() {}; 
Module.prototype.whatever = function() {}; 

var m = new Module(); 
m.whatever(); 

Infatti, avresti salvato un oggetto (la chiusura) dalla creazione, con la stessa uscita.

L'altro mio manzo con il modello di modulo è esso se lo si utilizza per l'incapsulamento privato, è possibile utilizzarlo facilmente solo con singleton e classi non concrete. Per creare classi concrete con dati privati ​​si finisce per avvolgere due closer, il che diventa brutto. Sono anche d'accordo che essere in grado di eseguire il debug delle proprietà pseudo-private del trattino basso è molto più semplice quando sono visibili. L'intera nozione di "cosa succede se qualcuno usa la tua classe in modo errato" non è mai giustificata. Crea un'API pubblica pulita, documentala e se le persone non la seguono correttamente, allora hai un programmatore scadente nella tua squadra. La quantità di sforzi richiesti in Javascript per nascondere le variabili (che possono essere scoperti con eval in Firefox) non vale l'uso tipico di JS, anche per progetti di dimensioni medio-grandi. Le persone non curiosano attorno ai tuoi oggetti per impararli, leggono i tuoi documenti. Se i tuoi documenti sono buoni (ad esempio usando JSDoc), si atteneranno ad esso, proprio come usiamo ogni libreria di terze parti di cui abbiamo bisogno. Noi non "manomettiamo" con jQuery o YUI, ci fidiamo e usiamo l'API pubblica senza preoccuparci troppo di come o cosa usi sotto.

Problemi correlati