Don't use IoC if you don't need it, but I'll explain why we need it in our case: some customers require different implementations.

That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configuration file.

We opt for configuration files. We opt for IDEs that can interpret Spring configuration files which means typos or incorrect dependencies do show up. This allows us to swap out implementations in case shit goes down without having to recompile, connect over a VPN to a remote desktop and hop through a few more hoops to get our class file on the other side. If you're not running your own apps on infrastructure you control (we should be so lucky), you have to take this sort of stuff into account. I'd love to be able to say "This is how stuff's set up. Deal with it."

(And when shit goes down, it is usually not at the place you were expecting it to happen, which means all kinds of configuration options for your bootstrapper would probably still fall short.)

IoC is automating the code required to wire up objects that are properly decomposed.

When you spend a long time learning how to effectively work with static languages, a few things come out. Dependency inversion and composition.

Where does this leave us? It often means we have classes that need one or more other objects when they are instantiated. This often results in chains of objects. For example,

  new Repository(new SessionFactory(new Configuration()))

Writing that code is pretty painful. Rather than dealing with long chains of dependencies, manually wiring everything up. You define mappings and let an IoC container do it for you.

Why not just wire everything up manually in static functions and be done with it? It is really hard to change static code and often impossible to test it in a language like Java/C#. There is almost nothing you can do to test a piece of code that calls out to User.find(1) in one of it's methods.

Why are there no IoC practices in ruby? Primarily because the second point is no longer true (you can test everything easily). I still think there is merit in knowing the dependency chain rather than just calling User.find(1) and hoping that something somewhere conjures up a database connection and configures everything correctly, at the correct time.

IoC is control and automation. Those are both powerful tools to any programmer.

I have found that in a lot of cases IoC ends up being completely misused and abused in really horrible ways. One of the more common antipatterns I encounter is creating an interface for every single thing in the application ("because hey, the implementation might change and it'll be easy to swap out"). No, if you're building a webshop or a task management application, abstracting and injecting your business logic or domain objects is as stupid as it gets.

I always keep hearing this argument "but something will change". No, it won't. Is it really worth introducing all this boilerplate nonsense into the application just for the off chance of something changing at some point? And even if that happens, don't you think you're better off just doing whatever modifications are necessary vs. putting all this crap into your application?

The only scenario where I've found IoC to make sense is when an application depends on a module and that module REALLY needs to be swapped out with another one. I once had that with a stock market analysis application that depended on X service for data feeds, but X service suddenly stopped working and I could just inject Y service instead without having to change anything else. But even in that case IoC container would've been redundant as plain old DI does the job just fine. That was the only thing in the application that I wrote that way because I didn't want to hard code an external dependency (that I have no control over) into my application.

But what I keep encountering is the cargo cult approach to programming where IoC is done for the sake of IoC and everything is injected for the sake of being injected, with no rational explanation as to why. It's quite terrible really.

It turns out that there is a problem with instantiating everything manually in main if you have a lot of components: it becomes non-trivial to figure out the order of instantiation.

This problem will typically surface whenever you add a dependency between existing components. If the dependency is currently instantiated after the changed component, it will have to be moved up so it is instantiated earlier. But then it turns out the dependencies of that component also need to be moved up etc.

To deal with this you then have to calculate a "dependency rank" for each component (i.e. 0 for components without dependencies, and x+1 for components where the max rank among the dependencies is x) just to figure out a new order that works.

This problem doesn't exist if you use a dependency injection container with configuration in code, because the order of component registration is not important.

According to Martin Fowler [1], Inversion of Control is an alternative to using a Service Locator:

  > In the Java community there's been a rush of lightweight
  > containers that help to assemble components from
  > different projects into a cohesive application.
  > Underlying these containers is a common pattern to how
  > they perform the wiring, a concept they refer under the
  > very generic name of "Inversion of Control". In this
  > article I dig into how this pattern works... and
  > contrast it with the Service Locator alternative. The
  > choice between them is less important than the principle
  > of separating configuration from use.

[1] http://martinfowler.com/articles/injection.html

(edit: Also, the Spring Framework has had alternatives to XML configuration for years: http://www.ibm.com/developerworks/webservices/library/ws-spr...)

I'm pretty sure IoC here refers to "inversion of control" (http://en.wikipedia.org/wiki/Inversion_of_control). I had to look it up though, I find it a bit silly that even the original article doesn't spell this out in the first sentence.

I guess it's super-obvious from context (and the claim of the title) so I guess I'm just not very smart, today. Oops.

I think the title's a bit misleading though... This guy is obviously talking about dependency injection.

Things like callbacks, observers, events, ... are also types of IoC.

A lot of people in this thread point out that modern IoC containers are good because they can automatically wire up your component tree for you, which is such a hassle to figure out and code manually in a place like main().

This component tree is the core of your application architecture. If the classes are well named, a big part of the application structure should become clear to someone reading your hand-coded main(). Also, if this is such a pain to figure out, why are you using components at all?

I find the idea of splitting functionality into classes but having no clue how these classes relate to one another a tad scary, really. I usually have a picture of the entire component tree on the wall near our team. It's great for pointing at when discussing design, and it's trivial to draw.

Writing a main() really shouldn't be more work than copying that picture into code. A tad tedious, but never more than an hour of work. Why add all that IoC complexity for saving 60 minutes. ? Why replace an excellent starting point for new team members to dive into code by a library that does magic?

Deployment variability doesn't cut it for me. Nearly always, you can foresee which things may need to be variable, and which aren't. Explicitly make those configurable, instead of all classes and their arguments like you'd do in Spring. In your main(), just if or switch over these config settings to instantiate the right class. Again, very readable, and you strongly convey intent to code readers.

Sure you have to use it where it makes sense, but IoC containers and frameworks like Spring can really make things easier. If you have to talk to anything complex (pick your messaging poison), need to keep transactions across these items, need to run under multiple different web containers and swap out configuration you are going to have some messy code to handle all of this sort of stuff. For enterprise integration problems I will pick Spring any day. For instance I can write a complex messaging bridge between two different messaging systems using nothing but some xml configuration. The mess of doing all the JNDI lookups, getting all my XA transactions right, handling firing messages after certain things happen all can be done without explicitly putting things all over the code. The beauty of IoC containers and AOP programming is that you can mix in a well tested piece of code across all your application with minimal effort. You can mixin authentication, transaction management, request cleanup, caching, etc. without making major changes to your app.

I know there are many people here that might crucify me for the opinion but I call bullshit. They just have never had to work on something sufficiently complex where IoC and frameworks like Spring can become a huge time savings. Obviously with any tool you have to make sure you don't chainsaw off your leg, and its really stupid to do certain things with any tool. The black magick of aop and IoC can make reasoning about things a little harder, but the shear power of the tool makes solving hard problems in complex applications tractable. Try auditing transaction management in an application with 10 thousand tables written by hundreds of people of various experience levels. Or just use spring transactions and inject the well tested behavior across the entire application.

Most places I have seen DI frameworks being used, they solve a problem the programmer shouldn't be having in the first place.

I found that a sweet spot between wiring-by-code and wiring-by-container-and-configuration-dsl is using a dynamic language for wiring (say, Rhino, which is very lightweigth): you have the flexibility of wiring-by-code and can easily change the configuration purely by deployment (without recompiling anything)

Younger IoC frameworks aim for configuration in code, allowing for a much more dynamic usage.

Examples (c#) * Autofac * Ninject

First of all, the author doesn't hate IoC and Containers, he hates XML registration (with good reason). I can't say anything about Java, but in C#, when you use modern IoC frameworks like StructureMap and AutoFac, all registration of components takes place in code, using generics and lambdas. This allows you to easily wrap your services in interfaces, de-coupling code and making things much more testable, especially if you use a good mocking framework like Rhino. When you combine DI/IoC with ideas like the Onion Archtecture (http://jeffreypalermo.com/blog/the-onion-architecture-part-1...), writing readable, testable, flexible, maintainable applications becomes supremely easy.

Do I understand correctly that the writer's main concern is that DI configuration is done in XML files, or that configuration takes place at run-time, instead of compile-time?

Maybe you should be using C#. As a community we fight hard to reject xml configuration, favoring type safe lambda expressions instead. Anything that ignores the type safe guarantees that C# offers quickly does. There was briefly a spring.net but it quickly died for this reason.

Java culture (IDE-dependence, AbstractFactoryVisitorFactory patterns, Maven and XML monstrosities) is hideous. It's based on the idea that reading code is a lost cause. You can no longer trust code, so you need all these wonky tool configurations to compensate for the fact that you're trying to make an army of inept programmers build something that is (unless it fails) going to become the next generation's legacy bloatbomb.

IoC is an usual technique and buzzword from the C#/Java + XML + ORM + SQL hell.

There are many programmers working in the Real-World [TM], powering great apps and webapps, using saner technologies who have never heard of the term.

I wrote my own IoC container (a clone of picocontainer IIRC) to see what the fuss was about when the term started to become fashionable. No big deal. It can help reproduce various states (for examples in testing environments) to more easily test your app.

Sure people will say: "You need an IoC container to do DI, what you're talking about is DI, not IoC".

But, fundamentally, it is once again related to "state" and the difficulty to recreate a state in {dev,pre-prod,prod,whatever}.

So it's once again a "solution" missing the bigger picture.

Sure, people stuck in the "stateful OO" mindset will love IoC and, honestly, if you're stuck in such an hell IoC can be useful. With the caveat that IoC makes it much harder to reason about what's going on when some shit hits the fan.

"Every problem can be solved with another layer of abstraction, except the problem of too many layers of abstraction"

But there's light at the end of the tunnel. There are other ways to design great apps.

And to make you feel even better: being "smart" as nothing to do with knowing every technology out there ; )

> new Repository(new SessionFactory(new Configuration())) > Writing that code is pretty painful.

If you think you are making things less painful by obfuscating the code snippet above I would challenge you to think about what you are doing. The above is incredibly clear. There is no doubt what is happening and if you screw up the compiler will yell at you.

If you obfuscate it through annotations and force readers of your code to try to reason about how the system will behave runtime, you have added exactly zero value. You have only degraded the readability and understandability of the system.

A little extra typing never killed anyone.

  ...
  public Repository(ISessionFactory factory)
  ...

Everything you're saying is true. But so is a lot of what the author said. Especially in the last section.

I've run into situations with Windsor along the lines of what he describes, and it really is a distressing situation to be in. You're happily coding along, whipping the project together, hacking decorators, auto-registering everything with a great set of conventions, and generally having a grand old time. And then something goes kachunk and suddenly it's damn near impossible to figure out how to tell the container exactly how everything needs to be wired up without creating a raft of custom dependency providers to deal with special cases that the container just wasn't designed to handle properly. And the configuration becomes increasingly diffuse, devolving into a mishmash of conventions, manual registrations, and registrations that are implied by custom implementations of IFooResolverProviderFactory, until eventually you realize that you're working with a modern-day edition of what Dijkstra was talking about when he wrote GOTO Considered Harmful. And at that point it might be time to tearfully say goodbye to the IoC container and hand code some abstract factories, because not only will they be less opaque but you'll soon discover to your own horror that they actually reduce the SLOC count.

But - butbutbutbutbut - where I depart with the author is in thinking that this means that IoC containers are bad. Quite the contrary. Avoiding an IoC container because your dependency graph might, just might turn out to be more complicated than what the container was designed to handle is a premature optimization. And will probably lead to worse code than what you'll get if you start out with an IoC container and are forced to give it up later, since using an IoC container really does encourage SOLID code.

I guess what I'm saying is, IoC containers are only "mostly amazingly great." It's still a young technology with some kinks to work out. Even venerable old Windsor is still experiencing significant API flux. They don't necessarily have an answer to every use case yet, even if they are getting damn close.

Oh, and writing libraries. If you're a library, you are not the composition root, by definition. And if you're not the composition root, you don't get to use an IoC container. Sorry. Have a facade.

I think the issue is that there is no such thing as Java culture, there is Enterprise culture which is responsible for all that you said above. But there is a start of a new "Java culture" which is encouraging, see what Google did with Guava, see the Java version of Play framework, even Spring framework 3+ is not that bad, no XML, all annotations, JPA is nice as well. Look at stuff done by Yammer, Twitter, Google and other Java/Scala based companies.

I wouldn't go and dismiss one of the most popular Enterprise frameworks, as a user of Spring / Hibernate for last 7+ years, it makes a lot of sense to me in the enterprise context, just like Ruby on Rails and Play Framework makes sense to me in the SaaS contect, for instance, having Play framework with a Spring module is a nice interim solution for bringing newer technology to the enterprise world.

It all depends on what you need to be doing. Spring is great for a large enterprise app, that have long lifetime, needs to connect to legacy stuff, needs common enterprise integration patterns etc.

Also if you check SpringSource latest stuff, you'll find out they are investing in lot's of cool new things, e.g. the scripted text editor - (https://github.com/scripted-editor/scripted/) and are influenced a lot by the Rails, Django, Node.js and Play communities.

The enterprise world is not that stupid, it's perhaps just a bit behind but it's still making tons of money from it's software, in billions, and it's more likely to be written in Spring / Hibernate than with Rails / ActiveRecord.

Just give it some time and patience.

Always love all the Java hate on ycomb. I'm not sure how a dynamically code hotswapping Ruby app with 10k classes and 1k domain objects works, but I suspect many of the same patterns emerge as have been solved in Java.

Not all of Java culture is like this. There's a ton of really great code out there. Take a look at any Android library. There's no damned Spring anywhere.

Or switch to Scala like me.

> It's based on the idea that reading code is a lost cause.

I would argue that it is based on the idea that there's going to be too much code to read it all, and that knowing you need to use something shouldn't automatically entail knowing how to create something.

In our defense, have you tried reading Java code?