Return to Question

Updated link for OCP

edit approved Jan 2, 2018 at 9:03

These days a question popped out in my mind:

Does the way we Javascript go against almost everything that is considered a good practice in traditional Software Development?

I have a series of question/observations related to this statement, but in order to respect StackExchange's format, it will be better if I split them into different questions.

Module requiring

Standard Javascript code nowadays looks like:

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

Advantages

Encapsulation: the module works standalone and know everything it need to perform its functions.
As a colorary, it's easier to clients to use the module.

Disadvantages

Poor testability: this is standard when not using DI, but in dynamic languages, such as Javscript it can be circumvented* by modules like mockery or rewire.
It certainly violates the DIP -- not to be confused with Dependency Injection. -- since I can only import concrete modules.
It probably violates the OCP OCP -- for example, imagine that I have a log module that writes to the file system (through fs module). If I want to extend this log module to send it to the network, it would be very hard.

_{* This might work with CommonJS or even AMD modules since they are implemented mostly in the user-land. However, I'm not sure how this could be possible with ES6 import syntax.}

Dependency Injection

Using dependency injection, it would be more like:

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

Advantages

Increased testability: now it's easier to stub/mock someModule, even using the ES6 syntax.
It's possible to honor the DIP: not necessarily though, as the client module can still be programmed to the implementation and not an interface.

Disadvantages

Broken encapsulation: the main question remaining is:

Ok, then who will create/require the dependencies?
Doing that in every client of the module seems very WET.
This would probably require me to use a DI Container in order to be feasible in a real project.

So, the real question here is:

Why Javascript developers tend to lean towards the first approach?

Is this just "the Javascript way"?

I myself write code like this most of the time. I've had my fair share of test setup using mocking libraries, but it always felt kind of wrong doing so.

Am I missing something?

These days a question popped out in my mind:

Does the way we Javascript go against almost everything that is considered a good practice in traditional Software Development?

I have a series of question/observations related to this statement, but in order to respect StackExchange's format, it will be better if I split them into different questions.

Module requiring

Standard Javascript code nowadays looks like:

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

Advantages

Encapsulation: the module works standalone and know everything it need to perform its functions.
As a colorary, it's easier to clients to use the module.

Disadvantages

Poor testability: this is standard when not using DI, but in dynamic languages, such as Javscript it can be circumvented* by modules like mockery or rewire.
It certainly violates the DIP -- not to be confused with Dependency Injection. -- since I can only import concrete modules.
It probably violates the OCP -- for example, imagine that I have a log module that writes to the file system (through fs module). If I want to extend this log module to send it to the network, it would be very hard.

_{* This might work with CommonJS or even AMD modules since they are implemented mostly in the user-land. However, I'm not sure how this could be possible with ES6 import syntax.}

Dependency Injection

Using dependency injection, it would be more like:

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

Advantages

Increased testability: now it's easier to stub/mock someModule, even using the ES6 syntax.
It's possible to honor the DIP: not necessarily though, as the client module can still be programmed to the implementation and not an interface.

Disadvantages

Broken encapsulation: the main question remaining is:

Ok, then who will create/require the dependencies?
Doing that in every client of the module seems very WET.
This would probably require me to use a DI Container in order to be feasible in a real project.

So, the real question here is:

Why Javascript developers tend to lean towards the first approach?

Is this just "the Javascript way"?

I myself write code like this most of the time. I've had my fair share of test setup using mocking libraries, but it always felt kind of wrong doing so.

Am I missing something?

These days a question popped out in my mind:

Does the way we Javascript go against almost everything that is considered a good practice in traditional Software Development?

I have a series of question/observations related to this statement, but in order to respect StackExchange's format, it will be better if I split them into different questions.

Module requiring

Standard Javascript code nowadays looks like:

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

Advantages

Encapsulation: the module works standalone and know everything it need to perform its functions.
As a colorary, it's easier to clients to use the module.

Disadvantages

Poor testability: this is standard when not using DI, but in dynamic languages, such as Javscript it can be circumvented* by modules like mockery or rewire.
It certainly violates the DIP -- not to be confused with Dependency Injection. -- since I can only import concrete modules.
It probably violates the OCP -- for example, imagine that I have a log module that writes to the file system (through fs module). If I want to extend this log module to send it to the network, it would be very hard.

_{* This might work with CommonJS or even AMD modules since they are implemented mostly in the user-land. However, I'm not sure how this could be possible with ES6 import syntax.}

Dependency Injection

Using dependency injection, it would be more like:

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

Advantages

Increased testability: now it's easier to stub/mock someModule, even using the ES6 syntax.
It's possible to honor the DIP: not necessarily though, as the client module can still be programmed to the implementation and not an interface.

Disadvantages

Broken encapsulation: the main question remaining is:

Ok, then who will create/require the dependencies?
Doing that in every client of the module seems very WET.
This would probably require me to use a DI Container in order to be feasible in a real project.

So, the real question here is:

Why Javascript developers tend to lean towards the first approach?

Is this just "the Javascript way"?

I myself write code like this most of the time. I've had my fair share of test setup using mocking libraries, but it always felt kind of wrong doing so.

Am I missing something?

deleted 35 characters in body

Source Link

edited Nov 27, 2016 at 16:48

candied_orange

119.7k
27
233
369

_{These days a question popped out in my mind:} These days a question popped out in my mind:

_{Does the way we Javascript go against almost everything that is considered a good practice in traditional Software Development?} Does the way we Javascript go against almost everything that is considered a good practice in traditional Software Development?

_{I have a series of question/observations related to this statement, but in order to respect StackExchange's format, it will be better if I split them into different questions.}

I have a series of question/observations related to this statement, but in order to respect StackExchange's format, it will be better if I split them into different questions.

# Module requiring

Module requiring

Standard Javascript code nowadays looks like:

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

Advantages

Encapsulation: the module works standalone and know everything it need to perform its functions.
As a colorary, it's easier to clients to use the module.

Disadvantages

Poor testability: this is standard when not using DI, but in dynamic languages, such as Javscript it can be circumvented* by modules like mockery or rewire.
It certainly violates the DIP -- not to be confused with Dependency Injection. -- since I can only import concrete modules.
It probably violates the OCP -- for example, imagine that I have a log module that writes to the file system (through fs module). If I want to extend this log module to send it to the network, it would be very hard.

_{* This might work with CommonJS or even AMD modules since they are implemented mostly in the user-land. However, I'm not sure how this could be possible with ES6 import syntax.}

Dependency Injection

Using dependency injection, it would be more like:

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

Advantages

Increased testability: now it's easier to stub/mock someModule, even using the ES6 syntax.
It's possible to honor the DIP: not necessarily though, as the client module can still be programmed to the implementation and not an interface.

Disadvantages

Broken encapsulation: the main question remaining is:

Ok, then who will create/require the dependencies?
Doing that in every client of the module seems very WET.
This would probably require me to use a DI Container in order to be feasible in a real project.

So, the real question here is:

Why Javascript developers tend to lean towards the first approach?

Is this just "the Javascript way"?

I myself write code like this most of the time. I've had my fair share of test setup using mocking libraries, but it always felt kind of wrong doing so.

Am I missing something?

_{These days a question popped out in my mind:}

_{Does the way we Javascript go against almost everything that is considered a good practice in traditional Software Development?}

_{I have a series of question/observations related to this statement, but in order to respect StackExchange's format, it will be better if I split them into different questions.} # Module requiring

Standard Javascript code nowadays looks like:

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

Advantages

Encapsulation: the module works standalone and know everything it need to perform its functions.
As a colorary, it's easier to clients to use the module.

Disadvantages

Poor testability: this is standard when not using DI, but in dynamic languages, such as Javscript it can be circumvented* by modules like mockery or rewire.
It certainly violates the DIP -- not to be confused with Dependency Injection. -- since I can only import concrete modules.
It probably violates the OCP -- for example, imagine that I have a log module that writes to the file system (through fs module). If I want to extend this log module to send it to the network, it would be very hard.

_{* This might work with CommonJS or even AMD modules since they are implemented mostly in the user-land. However, I'm not sure how this could be possible with ES6 import syntax.}

Dependency Injection

Using dependency injection, it would be more like:

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

Advantages

Increased testability: now it's easier to stub/mock someModule, even using the ES6 syntax.
It's possible to honor the DIP: not necessarily though, as the client module can still be programmed to the implementation and not an interface.

Disadvantages

Broken encapsulation: the main question remaining is:

Ok, then who will create/require the dependencies?
Doing that in every client of the module seems very WET.
This would probably require me to use a DI Container in order to be feasible in a real project.

So, the real question here is:

Why Javascript developers tend to lean towards the first approach?

Is this just "the Javascript way"?

I myself write code like this most of the time. I've had my fair share of test setup using mocking libraries, but it always felt kind of wrong doing so.

Am I missing something?

These days a question popped out in my mind:

Does the way we Javascript go against almost everything that is considered a good practice in traditional Software Development?

I have a series of question/observations related to this statement, but in order to respect StackExchange's format, it will be better if I split them into different questions.

Module requiring

Standard Javascript code nowadays looks like:

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

Advantages

Encapsulation: the module works standalone and know everything it need to perform its functions.
As a colorary, it's easier to clients to use the module.

Disadvantages

Poor testability: this is standard when not using DI, but in dynamic languages, such as Javscript it can be circumvented* by modules like mockery or rewire.
It certainly violates the DIP -- not to be confused with Dependency Injection. -- since I can only import concrete modules.
It probably violates the OCP -- for example, imagine that I have a log module that writes to the file system (through fs module). If I want to extend this log module to send it to the network, it would be very hard.

_{* This might work with CommonJS or even AMD modules since they are implemented mostly in the user-land. However, I'm not sure how this could be possible with ES6 import syntax.}

Dependency Injection

Using dependency injection, it would be more like:

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

Advantages

Increased testability: now it's easier to stub/mock someModule, even using the ES6 syntax.
It's possible to honor the DIP: not necessarily though, as the client module can still be programmed to the implementation and not an interface.

Disadvantages

Broken encapsulation: the main question remaining is:

Ok, then who will create/require the dependencies?
Doing that in every client of the module seems very WET.
This would probably require me to use a DI Container in order to be feasible in a real project.

So, the real question here is:

Why Javascript developers tend to lean towards the first approach?

Is this just "the Javascript way"?

I myself write code like this most of the time. I've had my fair share of test setup using mocking libraries, but it always felt kind of wrong doing so.

Am I missing something?

Tweeted twitter.com/StackSoftEng/status/802092241502306304

occurred Nov 25, 2016 at 10:11

Source Link

asked Nov 24, 2016 at 13:14

Henrique Barcelos

Module Requiring vs Dependency Injection in Javascript

_{These days a question popped out in my mind:}

_{Does the way we Javascript go against almost everything that is considered a good practice in traditional Software Development?}

_{I have a series of question/observations related to this statement, but in order to respect StackExchange's format, it will be better if I split them into different questions.} # Module requiring

Standard Javascript code nowadays looks like:

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

Advantages

Encapsulation: the module works standalone and know everything it need to perform its functions.
As a colorary, it's easier to clients to use the module.

Disadvantages

Poor testability: this is standard when not using DI, but in dynamic languages, such as Javscript it can be circumvented* by modules like mockery or rewire.
It certainly violates the DIP -- not to be confused with Dependency Injection. -- since I can only import concrete modules.
It probably violates the OCP -- for example, imagine that I have a log module that writes to the file system (through fs module). If I want to extend this log module to send it to the network, it would be very hard.

_{* This might work with CommonJS or even AMD modules since they are implemented mostly in the user-land. However, I'm not sure how this could be possible with ES6 import syntax.}

Dependency Injection

Using dependency injection, it would be more like:

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

Advantages

Increased testability: now it's easier to stub/mock someModule, even using the ES6 syntax.
It's possible to honor the DIP: not necessarily though, as the client module can still be programmed to the implementation and not an interface.

Disadvantages

Broken encapsulation: the main question remaining is:

Ok, then who will create/require the dependencies?
Doing that in every client of the module seems very WET.
This would probably require me to use a DI Container in order to be feasible in a real project.

So, the real question here is:

Why Javascript developers tend to lean towards the first approach?

Is this just "the Javascript way"?

I myself write code like this most of the time. I've had my fair share of test setup using mocking libraries, but it always felt kind of wrong doing so.

Am I missing something?

design-patterns javascript