CODEWITHSUNDEEP
javascriptangularjsdesign-patternsdependency-injection
sites
sites

Reputation: 21775

Angular.js - Javascript Dependency Injection

I read about DI and DI in Angular.js.

From what I understand DI in Angular.js means that Angular.js is allowing controller, factory, service, or others, to specify dependencies, without the need of creating the dependency.

Questions:

  1. In some point dependency has to be created, making the place where the dependency was created not DIed, how do I understand this?

  2. What if I have:

    var thing = function(dep){
  this.dep = dep || new depCreator();
}

    is this DIed? or depends whether dep is passed to the function?

  3. From what I see, DI means allow to set a dependency, being it in a function or object, at the end, would it mean to separate initialization/configuration/data from other parts of the program(logic? although we could have also initialization logic)?:

    var dep1 = 'qwe';
var thing = function(dep){ this.dep = dep; }
var diedThing = new thing(dep1);

    This would allow to set dep1 in a configuration file, for example.

  4. If the plain JavaScript implementing DI is:

    var thing = function(dep){
  this.dep = dep;
}

    instead of 

    var thing = function(){
  this.dep = new depCreator();
}

    Is this right?

    But what if depCreator depends on configuration files(or an extracted configuration), would this be DIed?

  5. When I read that Angular.js has(?) DI, is it correct to think that this DI means that Angular.js creates and searches dependencies for me? is there another meaning?

  6. Lastly, if DI is so complex, but means just to separate configuration from implementation(or logic?), why not call it single responsibility principle, i.e. the method does what the method does, the configuration does what the configuration does, and so on.

At the end, DI is to me a subjective concept, which is how do you imagine and split responsibilities in some application, is this even near to correct?

Sorry for the long question.

Upvotes: 0

Views: 155

Answers (1)

user2847643
user2847643

Reputation: 2935

  1. The place where the dependency is created does not depend on it. It's sole purpose is usually to create the "thing" and register it with the DI subsystem. There is nothing weird or suspicious about that.

  2. Why would you want to do this? Maybe instead depend on a service that creates the object for you if you need more flexibility.

  3. DI means dependency injection - exactly that, you don't create the thing you depend on yourself. Instead you ask for it and voila, it is made available to you. You don't need to know how to create it, who created it etc.

  4. If depCreator depends on the configuration files then that is fine. It can use them. Prior to registering dep with the DI subsystem it can do just about anything. That is what you would do, create a service/factory depCreator that would register dep and make it available for other components of your app.

  5. No question mark. Angular has a DI subsystem and it is actually one of the core ideas behind angular. Angular provides many components for you out of the box ready to be injected, the rest you have to create and register on your own.

  6. I don't know if I would say DI is complex. Maybe it is tricky to implement, I wouldn't know, but once you learn to use it you will not want to go back. DI in angular might just be the easiest to use I have ever seen. It's so good it's sort of transparent. After a while you don't even notice it's there and it works so well.

Your last remark is sort of correct I think. It is in a way about separation of concerns the way I see it. But there are many, many good resources out there that explain DI so I will not elaborate here. As always I would recommend reading ng-book for more angular specific details.

Upvotes: 1

Related Questions