Dependency Injection/IoC

[Steve Naidamast]

Dependency Injection or DI is a highly complex framework that is perfect for those situations where one needs to rely on the application processes to be able to determine the type of object it requires. Such a requirement is most often found in highly complex applications such as financial trading applications or military war gaming simulations (military, non-commercial) as both require to be able to determine hundreds if not thousands of object types. That being said, the interest in DI in business development has become over infatuated with the powerful capabilities of DI whereby development teams believing they need such capabilities implement it into their applications as a course of development policies in their shops. The problem is that Dependency Injection has similar issues as those of complex inheritance schemes, many of which have been found to have failed, are performance hogs, or have become so complex as to make maintenance very difficult. Such issues with complex inheritance were outlined during the later 1990s and the early 2000s. The result is that today, one rarely hears anything regarding the successes of complex inheritance as much of such success is limited to military and scientific applications as well as highly complex financial applications and other such development endeavors in the business development arena. As a result, such applications are few and far in-between and not the norm for application development. DI does in fact have issues with efficiency simply due to its own interpretation of how to select the object types it requires. And if one is not careful, using DI can turn an application's performance into a sluggish nightmare. Admittedly, even with my very long career in software development and engineering which entailed the development of quite a number of complex systems, no one ever suggested the use of Dependency Injection since there simply wasn't a need for it. Most applications in business development do not require the interpretation of many different kinds of objects and so are quite capable of being developed with semi-loose coupling or tight coupling of objects. Besides, the idea of loose-coupling which has achieved an almost paradoxical paradigm of priority in many application development endeavors has only added to any application's complexity unnecessarily. Loose-coupling and other such paradigms such as DI have come about as a result of technical managers and leads "imagining" what-if scenarios for their application requirements. Such ru

[kdmote]

In my house I have some lighting fixtures that are hard-wired to the wall/ceiling (~tight coupling). Others just plug into an electrical outlet (~loose coupling). Guess which ones are easier to switch out for new models? And when I do so, I can be confident that the new lamp will work as long as it has a matching interface (which, in this country, is AC 120V). So at work, when I am testing code that includes a DatabaseConnection Object, if that object was injected rather than hardcoded, I can happily swap it out with a mocked version that shares the interface. So, thanks to that loosely-coupled DB object, my tests run much faster.

[RandyBuchholz]

Maybe this will help. IoC is a design/architecture concept, DI is an implementation approach. With IoC your are doing structural inversion on object lifecycles. Commonly an operating object will "new" any objects it needs and then invoke operations. With IoC the objects are supplied and the operating object invokes operations on this supplied object. So, behavior lives in the operating object, but the structure has been factored out to a higher level - inverted. Since Interfaces define behavior, they are a common construct in IoC/DI. The simplest implementation of IoC doesn't need DI. This is IoC:

Class Foo {
public string Bar(Decoder decoder, string inString){ return decoder.decode(inString); }
}

You have inverted control of lifecycle management. The caller creates and supplies the structure (the object doesn't "new" any ones it wants), and the operating object operates on these objects. More commonly, you do this in the constructor.

Class Foo {
readonly Decoder _decoder;
public Foo(Decoder decoder){
_decoder = decoder;
}
public string Bar(string inString){ return _decoder.decode(inString); }
}

In some ways, the operating object is less dependent because it doesn't have to manage the selection and lifecycle management of the used object. This is IoC (hard coded) in a nutshell. DI is one way to address hard coding. You can think of DI as a combined Lookup and Activator. You give DI a "key", it looks up the mapped object, instantiates it using an Activator, and passes out the instance. You can have 1:1 type situations, where the Key and Value are the same. I tell it Foo, and it gives me a Foo object. Or, you can have 1:Many. Interfaces help here. Because with IoC I have decoupled the structure from the behavior, and interfaces are about behavior, I can associate many Values with a Key.

interface IFoo {
    string Bar(string inString);
}

class FooOne : IFoo { }
class FooTwo : IFoo { }

lookup.Add(IFoo, FooOne);
lookup.Add(IFoo, FooTwo);

This provides another form of loosening dependencies and coupling.

class Foo{
    IFoo \_foo;
    public Foo(IFoo foo){ \_foo = foo }

}

The DI system "intercepts" object creation, inspects the constructor to see if any types are in the lookup, supplies those instances, and then lets the creation process resume. To your question about "new", with "new" I have to know the class and it'