2013-02-04 3 views
8

Io uso qualcosa del tutto simile al modello di progettazione custom objects nel mio codice normalmente.Perché utilizzare i cattivi effetti collaterali nei costruttori JavaScript?

Ma aggrotta le sopracciglia JSLint su costrutti come questo:

function MyClass() { this.init(); } 
new MyClass(data); 

Poiché l'oggetto viene scartato immediatamente dopo la creazione - non viene utilizzato per qualsiasi cosa. Possiamo ingannare JSLint per ignorarlo assegnandolo a una variabile, ma non cambia il fatto che JSLint (e indovino molti appassionati di JavaScript) scoraggi il pattern.

Quindi perché utilizzare gli effetti collaterali in un costruttore JavaScript visto come una cattiva pratica?

Per quello che vale, ho pensato che questo era un buon pratica perché:

  1. Hai una sola funzione di configurazione, quindi dovrebbe essere più facile da mantenere se per esempio stai gestendo un elenco di istanze di MyClass per l'accesso in seguito. (Spingere un oggetto su un array è un effetto collaterale, dovresti farlo dopo che il costruttore è tornato a essere "buona pratica" = difficile da mantenere.)
  2. Ha un proprio prototipo, quindi una "proprietà di classe": Firebug riporta questo come un'istanza di MyClass anziché solo Object. (Questo, a mio avviso, lo rende superiore agli altri modelli di progettazione.)
+0

JSLint scoraggia 'new MyClass' perché non lo si sta usando dopo averlo istanziato. quindi, viene usato solo per i suoi effetti collaterali. Invece, questo esempio potrebbe essere riscritto per fare uso di dependency injection come 'initialize (new MyClass());' (anche se questo esempio è così semplice da essere stupido). – zzzzBov

+0

Non assegni mai veramente istanze create di 'MyClass' a qualcosa (in altre parole, è un modo complicato di rendere' init() 'una sorta di metodo statico)? L'utilizzo "normale" di questo modello non attiverebbe gli avvisi JSLint. –

+0

@ FrédéricHamidi non mai, ma a volte avrà effetti collaterali che fanno il lavoro stesso, cioè non c'è nient'altro che deve essere fatto. Un costruttore di Persona potrebbe creare un'istanza di un oggetto di persona, ma al momento non è necessario che tu debba operare su quella persona. Nel caso in cui sia necessario, gli effetti collaterali si registreranno in un array per l'accesso successivo. – user1994380

risposta

8

Nel suo libro Clean Codice, Robert Martin dice

Gli effetti collaterali sono bugie. La tua funzione promette di fare una cosa, ma anche la fa altre cose nascoste ... sono mistrutti subdoli e dannosi che spesso si traducono in strani accoppiamenti temporali e dipendenze degli ordini.

Quello che hai descritto nel tuo commento riguardo gli array suona come uno "strano accoppiamento temporale".

+1

Risposta utile, grazie per i termini di ricerca e materiale di riferimento. Ho trovato questo correlato per chiunque abbia domande simili - [Blog di Mark Seemann su .NET] (http: //blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling.aspx) (non utilizza JavaScript). In attesa di risposte migliori, accetterò questo. – user1994380