Why do we need Spring framework? [closed]

Question

Hi I am new to String and is reading the article by Martin Fowler: http://martinfowler.com/articles/injection.html

He gave an example of MovieLister using a MovieFinder for finding movies. In this example, he first provided the code:

class MovieLister...
    private MovieFinder finder;
    public MovieLister() {
        finder = new ColonDelimitedMovieFinder("movies1.txt");
    }
}

He pointed out that you can't give MovieLister to your friend for reuse, unless your friend uses the same MovieFinder implementation and put the movies in the same txt file.

Yes, of course, this is NOT the way you write a component with a hope that someone can reuse it. Instead, as he progressed, you should write:

class MovieLister...
    public MovieLister(MovieFinder finder) {
        this.finder = finder;       
    }
}

Yes, that is better. Now your friend can take over your MovieLister and plug in his own code. To me, the story is complete. I miss the point why you need a Spring framework to inject the dependency. The dependency is injected to MovieLister by your friend's code. Full stop. All the Spring setup is equivalent to simply implement the MovieFinder interface and make such a call:

MovieFinder myMovieFinder = new MyMovieFinderImpl();
MovieLister myMovieLister = new MovieLister(myMovieFinder);

Simple, easy. I know you hard code the creation of the MyMovieFinderImpl instance in your code. But what's the point of moving this to XML but bringing so much other stuff? Since when programmers become so scared of compiling code and prefer changing XML without compiling to get everything done? I am sorry but I think I just miss the point. Every program uses dependency inject, decades ago. But in the old days, dependency is injected by programs using a library, or a DOS command line, or a GUI. Why now we need yet another way as to inject dependency?

Thank you.

Updated:

Well, many of you guys brought annotation up. In my sallow understanding of Spring, I may feel more comfortable using XML rather than annotation. At least there is a central place listing how the dependency is, in a way that is easier to understand. With annotation, no such central place. Instead, just magic happening. Wanna know what is passed in as the parameter? Go figure it out yourself and good luck. Yes, I know there are smart IDE plugins help navigate the code. But why we make one thing complicated in the first place and celebrate another thing that helps make our life easier? The truth that annotation makes code harder to browse and understand so people create IDE plugins for this is obvious enough that we may create unnecessary things in the first place, isn't it?

Answer 1

In the "old days" code was written as in the first example.

Spring is a library, which you say is one of the ways it was done in the "old days".

Implementations were rarely specified on the command line or via a GUI. Multiple implementations of the same functionality weren't needed as often because (a) systems were rarely as complex as they are today, (b) they didn't need to interoperate with other systems the way they do today, and (c) deep testing was implemented far less often.

What's "so much other stuff"? Spring is segregated; you can bring in only what you need.

Why did you ignore configuration via annotations?

The purpose is to use a generic, localized, known, standard mechanism. It is ludicrous to say that "every program used dependency injection, decades ago." I programmed decades ago, across a pretty wide swath of languages, and while we did similar things, we all had our own implementations, with varying levels of sophistication, and wildly varying levels of success.

Is Spring necessary for DI/IoC? No, and a host of other DI frameworks attest to this. Is it a well-known, essentially-standard way of doing it? Yep.

Answer 2

Do not confuse the principle (DI) with one implementation (Spring).

If you like DI but prefer doing the wiring in your code: Use Google Guice.

If you like DI but prefer doing the wiring in your code and optionally XML then use CDI (from the Java EE track of things).

If you like DI and love XML (or must change the behaviour of your application by reconfiguring things) then just use Spring.

If you do not like DI then ... ask another question.

It's good to have several implementations of the same principle.