When the IOC met Node.js

The age of No IOC

A simple example:

var Engine = require ('./engine ');
var Wheel = require ('./wheel ');

var car = function () {
  this.engine = new engine ();
  This.wheel = new Wheel ();
}

Car.prototype.run = function () {
  this.engine.run ();
  This.wheel.run ();
  Console.log (' Run car ... ');
}

Module.exports = car;

In the example, the car needs to rely on wheels (wheel) and the engine (engine) to run. In order to deal with this relationship, it is necessary to first artificially introduce engine and wheel through require, and then instantiate it through the new operation so that the car can really run.

This example is very simple, but there are some problems:

When require, you need to know the file location, filename, and exports of engine and wheel directly. Once a engine or wheel file name, location, exports change occurs, the require operation must be changed accordingly

Car is directly dependent on engine and wheel, so if we try to do unit testing, we find it very difficult to mock engine or wheel, either by modifying the engine, wheel code, or by modifying the car's code

This example has only 3 objects, and the reader may not think it matters much, so it's not a big deal to do directly. But what happens when the number of objects inside the system gets bigger? This may be the case for complex dependencies:

Such systems are tightly coupled, often resulting in difficult to maintain, difficult to refactor, and difficult to do unit testing, especially when a new person joins the team, also because this complexity becomes difficult, can not understand also change.