Is dependency injection by hand a better alternative to composition and polymorphism?

Question

First, I'm an entry level programmer; In fact, I'm finishing an A.S. degree with a final capstone project over the summer. In my new job, when there isn't some project for me to do (they're waiting to fill the team with more new hires), I've been given books to read and learn from while I wait - some textbooks, others not so much (like Code Complete). After going through these books, I've turned to the internet to learn as much as possible, and started learning about SOLID and DI (we talked some about Liskov's substitution principle, but not much else SOLID ideas). So as I've learned, I sat down to do to learn better, and began writing some code to utilize DI by hand (there are no DI frameworks on the development computers).

Thing is, as I do it, I notice it feels familiar... and it seems like it is very much like work I've done in the past using composition of abstract classes using polymorphism. Am I missing a bigger picture here? Is there something about DI (at least by hand) that goes beyond that? I understand the possibility of having configurations not in code of some DI frameworks having some great benefits as far as changing things without having to recompile, but when doing it by hand, I'm not sure if it's any different than stated above... Some insight into this would be very helpful!

Answer 1

The fundamental idea in DI is simply to push dependencies into objects, rather than letting them pull dependencies from outside. This was also called "inversion of control" earlier. This allows one to control dependencies much better, and - last but not least - to write code which is easy to unit test.

DI frameworks only build on top of this idea, and (partly) automate the often tedious part of wiring object dependencies together. This may otherwise require a significant amount of code in a larger project when done by hand.

To define dependencies, apart from external configuration files, it is also possible to use code annotations nowadays, e.g. in languages like Java and C#. These may bring the best of both worlds: wiring dependencies in a declarative style, but right within the code itself, where it logically belongs to. To me, the possibility of changing dependencies without having to recompile is not that valuable, as it is rarely done in real life (apart from some special cases), but introduces an often artifical separation of dependencies from the classes and objects defined within the code.

To return to your title question, DI is not an alternative to composition nor polymorphism; after all, it is made possible by these two.

Answer 2

The best article I've ever read on the topic was James Shore's. I've been doing "DI by Hand" for ages, as part of abstraction and polymorphism. So after I got into the professional world and I kept hearing that term being thrown around I had a large disconnect between what I thought the word should mean and what it actually means:

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

That's from Shore's post, which cleared everything up for me. For example:

Given

class Engine {public abstract void start()}
class V8 extends Engine {...}
class V6 extends Engine {...}

Instead of writing:

class Car
{
    private Engine engine;
    public Car()
    {
        this.engine = new V6();
    }

    public void start()
    {
        this.engine.start();
    }
}

Your write something like this:

class Car
{
    private Engine engine;
    public Car(Engine a)
    {
        this.engine = a;
    }

    public void start()
    {
        this.engine.start();
    }
}

...

Car F = new Car(new V8());

And this prevents the Car instance from having to handle specific Engine details. A car just needs an engine, it doesn't care which one as long as it implements the basic Engine functionality. That is, your Car class is not tied to specific implementation dependency; it's "injected" elsewhere, potentially at runtime.

This specific Car example uses the sub-type of DI called "Constructor Injection", which just means that the dependency was handed over as a constructor argument. You can also use a setEngine(Engine a) method for "Setter Injection", and so on, but these sub-types seem pedantic to me.

A bit further, though, many DI frameworks provide the boilerplate to connect a bunch of these more abstractly referenced things up to one another.

That's it.

Answer 3

I am not an expert as I only started using DI in the past couple of years, but a few of the useful themes/functionalities of DI containers that I've noticed are (which I don't think of as products of composition/polymorphism (but I may stand to be corrected on that):

• central hub of object creation
• provide singletons on a per thread basis
• aspect oriented techniques such as interception

Answer 4

Apart from DI, there is a class composition configuration at the root application (instead of configurating using xml). There is no need for any DI or IoC framework, even though they can tidy up the class composition configuration, particularly for large projects. This is because the DI framework normally come with container that implement additional features, such auto-wiring, that helps to configure class composition. You can read my blog entry to extract my understanding on this topic.