[nailer]

I don't get dependency injection. I come from languages that I am told don't have it. But when I read the Wikipedia page for DI, I get:

"a dependent consumer

a declaration of a component's dependencies, defined as interface contracts

an injector (sometimes referred to as a provider or container) that creates instances of classes that implement a given dependency interface on request."

Wait, I still have to declare dependencies, just like the import statement in python, require.js in JS, etc. which are apparently not 'dependency injection' systems? And this just adds, er more code?

That same wikipedia page mentions dynamically loaded dependencies while also mentioning 'a declaration of a components dependencies' which sure doesn't sound dynamic to me.

Does anyone care to provide a better explanation of what dependency injection gives me over the existing common dependency mechanisms?

[JanezStupar]

Python itself has DI built in throughout the stack.

Building Java like DI mechanisms is cargo cultism. The whole point of DI in Java is to work around its static typedness, so one can perform runtime binding of components in a dynamic manner.

Three quarters of cool Java and .NET "design patterns" are just band aids around semantic limitations of these languages.

[altcognito]

> The whole point of DI in Java is to work around its static typedness.

So, coding the configuration of your application is an ideal way to work. Interesting.

[JanezStupar]

Yes!

http://thedailywtf.com/Articles/Soft_Coding.aspx

If Java guys wouldn't have stuck their heads up their asses so hard, they could use something like scripting language, with the whole debugging and library stack to configure their applications instead of building byzantine XML based DSL's.

Frankly my python (code!) based config files work a lot better than similar XML based config files in Android. Except mine are debuggable and readable.

The whole point of software is that it gets changed on demand. That's why it is called SOFTware.

Edit: Or perhaps you are going to enlighten me why XML config files are not code? Then you might be able to explain where configurations cross the border of "code". Is configuring Sharepoint coding or configuring?

[altcognito]

Readable to who? Machine readable? Which is easier to change or debug: dependencies which are in predictable locations OR buried within your source code? Could you say the same thing about arbitrary python code? Now I have to learn the way you decided to implement what's already been done dozens of times before I even get to reading the actual logic of the application.

Also, for the record, if you're debugging the infrastructure of how objects are created, you're doing it wrong. You probably don't understand the framework you're working in.

[JanezStupar]

You are missing the point. I am not saying that one should make mess of his code.

I am merely saying that configuration files are code too. They need to be tested, debugged and refactored. Writing code in XML seems a retarded way to go about it. If my language would prevent me from writing configurations in itself in a sane manner, I would rather use another language with a solid toolchain for this part of the job. Than go and build my own DSL in XML of all things.

If you are of an open mind, go check how Django is configured and extended and compare it to your run of the mill enterprise framework.

And let me tell you that I did my fair share of enterprisey "configurable and extendable" framework shit. And its all a lie. You cannot make "simplified" languages that will enable you to be more "flexible" or to let amateurs to program system behavior. Always these kinds of interfaces gobble up way more developer hours than they save in the long run. Often programmers resort to writing programs that offer a sane API for writing these kinds of configs.

One should simply build a quality API and document it well.

[dragonwriter]

> So, coding the configuration of your application is an ideal way to work. Interesting.

You're coding it one way or another; whether you do the whole thing in Python, or most of it in Java and some of it in XML (or YAML, JSON, etc.) because Java is inconvenient.

The main motivation for using XML (YAML, JSON, etc. are equivalent for this purpose) "configuration" over Java "coding" for certain pieces is that: 1. XML, unlike Java, doesn't need to be AOT compiled 2. XML is more naturally suited than Java to a succinct declarative style 3. Its easier for external tools to work with and modify XML than Java, which may be useful for configuration tools.

In many other languages, one or more of these advantages of XML over the main coding languages is less significant or entirely absent (interpreted/JIT-compiled languages avoid #1; functional and many modern multi-paradigm languages avoid #2; Lisps and other easily-parseable homoiconic languages avoid #3.) Depending on the language you are using and which of these factors is important to your use case, there may be no significant reason to bear the cost of a second language for configuration.

[altcognito]

> You're coding it one way or another;

Yes. I agree, most of these frameworks are in some sense a DSL. I cannot agree that writing in a different language changes the underlying purpose and function of separating configuration from the code.

[dragonwriter]

> I cannot agree that writing in a different language changes the underlying purpose and function of separating configuration from the code.

Language features effect the degree to which the underlying purpose and function of separating service identification from other code requires framework support, and the style of framework which is most sensible to support it to the degree that framework support is necessary.

[altcognito]

I can agree with that. Untyped languages seem to allow for better gradients of separation as well as tend to work with a wider variety of tools. It's not always good, but it usually quicker to start with.

[manojlds]

Thank you for treating .NET as a language and ignoring languages like F#

[JanezStupar]

I was aware of this dichotomy when writing the post. And I find .NET stack much better than JVM stack.

In fact while I couldn't stomach working in Java I would be much more willing working with C#, not to mention other .NET citizens. But in general as a spectrum, the toolkits and libraries of .NET and Java share architectural and design patterns.

However the .NET stack does have built in languages (Javacript and F#) that can be used to glue together the rest of the system in a sane manner. The capability is there, however standard operating procedure is sadly still using shitload of XML's.

[arethuza]

In a stackoverflow thread I found a reference to this classic:

'"Dependency Injection" is a 25-dollar term for a 5-cent concept.'

http://www.jamesshore.com/Blog/Dependency-Injection-Demystif...

I do think it is a useful concept - but I sometimes think it gets a bit blown out of proportion.

[camus]

At its core DI is basically constructing instances of objects with the help of other objects. So you have constructor injection , setter injection , property injection ,etc ...

Now that you got these huge object graphs, you need a way to wire them without pain.

That's where service locators and IOC containers are handy.

A service locator is basically a registery that holds the dependencies and you instanciate objects that way

     container.createDefinition("MyClass").injectProperty("prop1","MyOtherClass").injectConstructor("MyThirdClass","MyLastClass")

then

    myInstance = container.create("MyClass")

or whatever

The question is while dependency injection is good practice in general , do Pythonists need IOC containers or Service Locators? etc ...

AMD in javascript has nothing to do with dependency injection. AMD is not about instanciating objects but resolving file dependencies.

[gizzlon]

"At its core DI is basically constructing instances of objects with the help of other objects."

Why would you wan t that in python? Doesn't python have higher order functions?

[kyllo]

Exactly, in a dynamic language with first-class functions you don't need to create object factories just to pass around static methods between scopes.