4 ms·

>> where programmatic wiring and modules already solve the problem in an idiomatic way Can't agree with that. Not sure what you mean by 'programmatic wiring'

>> where programmatic wiring and modules already solve the problem in an idiomatic way Can't agree with that. Not sure what you mean by 'programmatic wiring' as it sounds vague, but certainly modules do not solve the same problem that DI solves. Modules, (assuming you mean stuff you require() or equivalent), provide module-level dependencies but do not provide object instances. For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors). DI allows you to provide an object with object instances it depends on without tightly coupling said object to those dependencies (pass a Door instance into a House instance, advantage being you can pass in any type of Door and House doesn't need to care - thanks polymorphism)! I'm not sure that's a great explanation, but it's worth trying every now and then right? You seem to be making the argument that the language provides alternatives, and it's true that in dynamic languages you can eschew some of the benefits of DI by doing monkey patching instead (e.g. to mock out an object's 'tightly coupled' dependencies during testing), but to myself and many OOP proponents DI leads to cleaner design and simpler tests.

kyllo 12y ago
For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors). So what? What is so bad about House and Door being "tightly coupled"? Here's a House constructor that can take any kind of Door instance: function House(door){ this.door = door; } This is JavaScript, let's stop trying to make it into Java.
- nilliams 12y ago
  What you just wrote as a code example is Dependency Injection, it's just manual dependency injection as opposed to using an IOC container or any of the mechanisms Angular provides. I am very much in favour of the approach you posted. That's exactly how I write my code (I don't currently use Angular), but yep ... that's DI. As James Shore said 'Dependency Injection is a 25-dollar term for a 5-cent concept'. [1]. What you show in that code example is what in my head I call "poor man's DI" or ... "passing stuff in" but it's actually my favourite kind as it demonstrates the fundamental idea and is easy to explain to people - as soon as you start talking about IOC and service providers things start to get murkier. I think that's definitely where Angular is losing some people. You can get a long way with the basic "poor man's" approach. [1] http://www.jamesshore.com/Blog/Dependency-Injection-Demystified.html http://www.jamesshore.com/Blog/Dependency-Injection-Demystif...
  - fetbaffe 12y ago
    I remember the first time I heard the term Dependency Injection. I sounded really advanced and I felt like a fool not knowing about. Like have been living under a rock for last years. When I realized it was "passing stuff in" I wanted to shout, I have done that for years!
  - coldtea 12y ago
    >When I realized it was "passing stuff in" I wanted to shout, I have done that for years! Well, it's the "automatic" part that is important, not just the DI.
    - kyllo 12y ago
      So the setter gets called automatically, but now you have to store the object names as strings or in an XML file. How is that better?
      - coldtea 12y ago
        Loose coopling?
        kyllo 12y ago
        Well, now the different classes inside your application are more loosely coupled, but your business logic is more tightly coupled to a DI framework.
- watty 12y ago
  I felt the same way about DI until I watched this video: http://www.youtube.com/watch?v=_OGGsf1ZXMs http://www.youtube.com/watch?v=_OGGsf1ZXMs
  - ggregoire 12y ago
    Great video!
  - acjohnson55 12y ago
    Fantastic video. I think it nails what DI is good for, and furthermore, what a DI framework is good for. Not only that, but it's a faaaaar more elegant solution than what's been in Angular so far.
kuni-toko-tachi 12y ago
var prod_dependencies = { obj0: require('obj0'), obj1: require('obj1') }; var test_dependencies = { obj0: require('mockobj0'), obj1: require('mockobj1') }; var dependencies = test_dependencies; some_func(dependencies.obj0,dependencies.obj1); Javascript does not need Java-style dependency injection. Javascript's configuration language JSON is valid Javascript.
- nilliams 12y ago
  You're slightly off on your definitions - what you show in that example is dependency injection. You are injecting dependencies into `some_func` by passing them in. See my response to kyllo below. I think what you are arguing against is using further patterns to facilitate dependency injection, e.g. IOC containers, or what Angular uses (service locators).
- luikore 12y ago
  Not all JSON are valid javascript: http://timelessrepo.com/json-isnt-a-javascript-subset http://timelessrepo.com/json-isnt-a-javascript-subset

kyllo 12y ago

For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors). So what? What is so bad about House and Door being "tightly coupled"? Here's a House constructor that can take any kind of Door instance: function House(door){ this.door = door; } This is JavaScript, let's stop trying to make it into Java.

nilliams 12y ago
What you just wrote as a code example is Dependency Injection, it's just manual dependency injection as opposed to using an IOC container or any of the mechanisms Angular provides. I am very much in favour of the approach you posted. That's exactly how I write my code (I don't currently use Angular), but yep ... that's DI. As James Shore said 'Dependency Injection is a 25-dollar term for a 5-cent concept'. [1]. What you show in that code example is what in my head I call "poor man's DI" or ... "passing stuff in" but it's actually my favourite kind as it demonstrates the fundamental idea and is easy to explain to people - as soon as you start talking about IOC and service providers things start to get murkier. I think that's definitely where Angular is losing some people. You can get a long way with the basic "poor man's" approach. [1] http://www.jamesshore.com/Blog/Dependency-Injection-Demystified.html http://www.jamesshore.com/Blog/Dependency-Injection-Demystif...
- fetbaffe 12y ago
  I remember the first time I heard the term Dependency Injection. I sounded really advanced and I felt like a fool not knowing about. Like have been living under a rock for last years. When I realized it was "passing stuff in" I wanted to shout, I have done that for years!
- coldtea 12y ago
  >When I realized it was "passing stuff in" I wanted to shout, I have done that for years! Well, it's the "automatic" part that is important, not just the DI.
  - kyllo 12y ago
    So the setter gets called automatically, but now you have to store the object names as strings or in an XML file. How is that better?
    - coldtea 12y ago
      Loose coopling?
      - kyllo 12y ago
        Well, now the different classes inside your application are more loosely coupled, but your business logic is more tightly coupled to a DI framework.
watty 12y ago
I felt the same way about DI until I watched this video: http://www.youtube.com/watch?v=_OGGsf1ZXMs http://www.youtube.com/watch?v=_OGGsf1ZXMs
- ggregoire 12y ago
  Great video!
- acjohnson55 12y ago
  Fantastic video. I think it nails what DI is good for, and furthermore, what a DI framework is good for. Not only that, but it's a faaaaar more elegant solution than what's been in Angular so far.

kuni-toko-tachi 12y ago

var prod_dependencies = { obj0: require('obj0'), obj1: require('obj1') }; var test_dependencies = { obj0: require('mockobj0'), obj1: require('mockobj1') }; var dependencies = test_dependencies; some_func(dependencies.obj0,dependencies.obj1); Javascript does not need Java-style dependency injection. Javascript's configuration language JSON is valid Javascript.

nilliams 12y ago
You're slightly off on your definitions - what you show in that example is dependency injection. You are injecting dependencies into `some_func` by passing them in. See my response to kyllo below. I think what you are arguing against is using further patterns to facilitate dependency injection, e.g. IOC containers, or what Angular uses (service locators).
luikore 12y ago
Not all JSON are valid javascript: http://timelessrepo.com/json-isnt-a-javascript-subset http://timelessrepo.com/json-isnt-a-javascript-subset