use Perl

• Re: (Score:1)

  by Aristotle (5147)

  Hey, thanks for the feedback. :-)

  Yeah, Kragen Sitaker argued the same when I mentioned my article on IRC. To that I argue that the value of the Dependency Injection moniker is not in itself, so much as it is in naming the concept of a Dependency. If you recognise dependencies as such, then injecting them just falls out naturally from good OO design sense – that’s what I am saying in that article.

  Don’t miss my follow-up [plasmasturm.org] either on Henning Koch’s response [netalive.org] either, it picks up on som
  • Re: Dependency Injection Rocks (Score:1)

    by Adrian (66) <adrianh@quietstars.com> on 2005.10.30 5:36 (#44258) Homepage Journal

    Hey, thanks for the feedback. :-)

    You're welcome :-)

    To that I argue that the value of the Dependency Injection moniker is not in itself, so much as it is in naming the concept of a Dependency. If you recognise dependencies as such, then injecting them just falls out naturally from good OO design sense – that’s what I am saying in that article.

    I'd disagree with the "falls out naturally" bit. Well... kind of anyway.

    You're right that dependency injection techniques are a specific instance of the more general technique of removing hard coded dependencies. However I don't think that for many people the specific techniques of dependency injection are necessarily particularly obvious.

    To put it another way. The naming and description of Dependency Injection is a really good pedagogical tool for highlighting certain kinds of dependencies, and demonstrating a variety of ways of removing them.

    Indeed all design patterns are like this. The definition of design pattern could almost be something that "falls out naturally from good OO design sense" :-)

    In my experience people learn best from examples - and that's what design patterns are. Little nuggets of easily digestible good design.

    There's also the rise of the dependency injection frameworks. I'm uncertain that this would have happened without the naming of Dependency Injection.

    I know that since I started reading about IoC/DI I started noticing where I've been doing dependency injection in my own code. The thing that I hadn't noticed, until clever sods like Fowler went and named it, is that I'd been doing the same thing in a variety of different ways.

    Now that I've noticed that I can start thinking about better ways of abstracting out the DI stuff from the rest of the code, which is going to make the main flow of control easier to grok.

    Reply to This

    Parent