In questi giorni mi è venuta in mente una domanda:

Il modo in cui Javascript va contro quasi tutto ciò che è considerato una buona pratica nello sviluppo di software tradizionale?

Ho una serie di domande / osservazioni relative a questa affermazione, ma per rispettare il formato di StackExchange, sarebbe meglio se le dividessi in domande diverse.

Modulo richiesto

Oggi il codice Javascript standard assomiglia a:

const someModule = require('./someModule')

module.exports = function doSomethingWithRequest() {
  // do stuff
  someModule.someFunc()
  // do other stuff
}

vantaggi

• Incapsulamento: il modulo funziona da solo e conosce tutto ciò di cui ha bisogno per svolgere le sue funzioni.
• Come colorario, è più facile per i clienti usare il modulo.

svantaggi

• Scarsa testabilità: questo è standard quando non si utilizza DI, ma in linguaggi dinamici, come Javscript, può essere eluso * da moduli come mockeryo rewire.
• Certamente viola il DIP - da non confondere con l'iniezione di dipendenza. - dal momento che posso importare solo moduli concreti.
• Probabilmente viola l' OCP - ad esempio, immagina di avere un modulo di registro che scrive nel file system (tramite il fsmodulo). Se voglio estendere questo modulo di registro per inviarlo alla rete, sarebbe molto difficile.

_{* Questo potrebbe funzionare con CommonJS o persino con i moduli AMD poiché sono implementati principalmente nella terra dell'utente. Tuttavia, non sono sicuro di come ciò sia possibile con la importsintassi ES6 .}

Iniezione di dipendenza

Usando l'iniezione di dipendenza, sarebbe più simile a:

module.exports = function doSomethingWithRequest(someModule) {
  // do stuff
  someModule.someFunc()
  // do other stuff
}

vantaggi

• Maggiore testabilità: ora è più facile stub / deridere someModule, anche usando la sintassi ES6.
• È possibile onorare il DIP: non necessariamente, poiché il modulo client può ancora essere programmato per l'implementazione e non un'interfaccia.

svantaggi

• Incapsulamento rotto: la domanda principale che rimane è:

  Ok, allora chi creerà / richiederà le dipendenze?

• Farlo in ogni client del modulo sembra molto WET .
• Ciò probabilmente mi richiederebbe di utilizzare un contenitore DI per essere fattibile in un progetto reale.

Quindi, la vera domanda qui è:

Perché gli sviluppatori Javascript tendono ad appoggiarsi al primo approccio?

È solo "il modo Javascript"?

Io stesso scrivo codice come questo la maggior parte delle volte. Ho avuto la mia giusta dose di configurazione di test usando librerie beffardo, ma mi è sempre sembrato sbagliato farlo.

Mi sto perdendo qualcosa?

Sono principalmente un programmatore di PHP, ma sono stato in contatto con 4 team JavaScript per circa un anno.

Come programmatore orientato agli oggetti, il principio dell'iniezione di dipendenza sembrerebbe il modo migliore, tuttavia mi è stato detto diversamente da pochi sviluppatori JS. JS è un mondo completamente diverso.

Poiché JavaScript ti consente di applicare una patch scimmia a qualsiasi cosa utilizzando tecniche molto semplici, gli sviluppatori JavaScript hanno imparato ad adattare una tecnologia diversa su come costruire applicazioni JavaScript su larga scala. La maggior parte di questi sono costruiti come set di moduli autonomi, che espongono funzionalità attraverso le esportazioni pubbliche, nascondendo gli interni del modulo in modo da non consentire ad altri di riscrivere le funzioni su cui si fa affidamento.

L'approccio usuale di solito è addirittura quello di non esporre un costruttore, ma piuttosto esporre la costruzione di un oggetto usando un wrapper di fabbrica, per lo stesso identico motivo: se si dà a qualcuno l'accesso a un oggetto, possono istanziare direttamente sono autorizzati a cambiare qualsiasi cosa.

Sfruttando il design modulare, neghi ad altri di giocherellare con le tue funzioni che prevedi funzionino, ma hai ancora la possibilità di testare i tuoi moduli - attraverso l'API pubblica del file richiesto, l'API che hai creato.