A few posts ago I talked about Reactive Programming and how I have decided to make it my primary concern architectually when developing. I recently read on the ninject site that an advantage of using a dependency injection framework such as ninject is that depenencies can be inspected, modified and be conditional. This is interesting, as this sounds like it offeres advantages comparable to data-binding. Being able to evaluate functions and relationships between code modules or elements is definately positive in my book because it allows us to have more ability to reason over information we have already provided.

A real world example, that I have seen demonstrated, could be as follows:

if an application is being executed then provide an implementation of a service that calls to say flicker, or amazon etc.

at design time we still want our visual studio or expression blend to work, and it would be nice if it had some data to display. We can do this by injecting a different depenedency link. This link would point to a dummy service that would just display data to help us in the designer views.

For more depth see: http://jonas.follesoe.no/YouCardRevisitedImplementingDependencyInjectionInSilverlight.aspx

While this could be done without dependency injection, code would start getting consolidated and repeated leading to code smells (ie bad practices). It is also worth stating that the example of using a webservice and specifying different implementations is quite a simple example. With that said I think the true power of Dependency Injection not only leads to better plug-ability of code modules but also the reasoning over these bindings.