What are Dependency Injection & Spring Framework about? [closed]?

We use Dependency Injection (DI) to implement loose coupling. The choice of any particulary DI Container is not that important. Every time you create an instance of a class by using the new keyword, you tightly couple your code to that class, and you will not be able to substitute that particularl implementation with a different one (at least not without recompiling the code).

This would look something like this in C# (but would be equivalent in Java): public class MyClass { public string GetMessage(int key) { return new MessageService(). GetMessage(key) } } This means that if you would later like to use a different MessageService, you can't. On the other hand, if you inject an interface into the class and adhere to the Liskov Substition Principle, you will be able to vary the consumer and the service independently.

Public class MyClass { private readonly IMessageService messageService; public MyClass(IMessageService messageService) { if(messageService == null) { throw new ArgumentNullException("messageService"); } this. MessageService = messageService; } public string GetMessage(int key) { return this.messageService. GetMessage(key) } } Although this looks more complicated, we have now managed to follow the Single Responsibility Principle by ensuring that each collaborator does only one thing, and that we can vary both independently of each other.

Furthermore, we can now change MyClass' behavior without changing the class itself, thus adhering to the Open/Closed Principle.

Reconfiguration is overrated. The most important thing you get from using DI is testability. Since your classes don't depend on implementations but on abstractions you can replace them with mocks / stubs in your unit tests.

Example Without DI: class SaleAction{ private BillingService billingService; public SaleAction(){ billingService = new CreditCardService(); //dependency is hardcoded } public void pay(long amount){ //pre payment logic billingService. Pay(amount); //post payment logic } } In that example suppose you want to unit test the pre-payment logic and post-payment logic of SaleAction... you can't because SaleAction is coupled to CreditCardService and probably running your tests will generate fake payments. Now the same example with DI: class SaleAction{ private BillingService billingService; public SaleAction(BillingService service){ billingService = service; //DI } public void pay(long amount){ //pre payment logic billingService.

Pay(amount); //post payment logic } } Now SaleAction is decoupled from any implementation, which means that in your test you can do SaleAction action = new SaleAction(new DummyBillingService());. Hope that helps, there's also the article about DI, written by Martin Fowler that you can find here.

Effectively you are saying that DI frameworks, e.g. Spring, are overrated since it's trivial to replace dependencies with mocks in code without a framework. The creation of those mocks can be rather involved but I don't see any advantage in being able to swap them in and out for alternative mocks. – Adam Ralph Dec 30 '09 at 13:33 4 not relying on concrete implementations is at the core of OOP, not only of DI.

– Bozho Dec 30 '09 at 13:37 I don't say that frameworks are overrated. DI is mandatory for unit testing, and unit testing is mandatory for software development. – Pablo Fernandez Dec 30 '09 at 13:37 1 DI is not mandatory for unit testing.

– Bozho Dec 30 '09 at 13:40 2 @Pablo - "unit testing is mandatory for software development" - Well, I could not work without unit testing, but I don't think that even the majority of software has unit test coverage. – Thomas Jung Dec 30 '09 at 13:41.

Spring has turned into a huge framework, which may be confusing you if you are only trying to wrap your head around dependency injection. The Google Guice project is tiny and only does DI with pure Java--no XML and no extras. There's a nice introductory video explaining DI too.

code.google.com/p/google-guice.

Ken Fox. No, no. I will use Spring.

DI was mentioned because it forms the basis of the Spring Framework. I'm not interested in DI, I am interested mainly in Spring functionality. But I need to know what lays in the base.

– EugeneP Dec 30 '09 at 13:48 1 Spring has always been a huge framework, much more than DI. AOP has had equal billing since day one, as have the libraries. To say that Spring and Guice map one-to-one is as incorrect as saying the same for Spring MVC and Struts.

Spring includes functionality equivalent to both and more. – duffymo Dec 30 '09 at 13:51 @Ken Fox. All right, I don't really understand yet AOP, I've read that it deals with "crosscutting concerns", things like logging that occur in virtually every method of the class.

But tell me, all right, there's AOP. But it does not substitute DI, does it? – EugeneP Dec 30 '09 at 13:59 1 @EugeneP: Don't pick a framework and then see what it does.

There's an XP principle called YAGNI (You Ain't Gonna Need It) that has always been good to me. If you have a problem, find a solution, and if that brings you to a framework like Spring, at least you know where to start eating the elephant. – Ken Fox Dec 30 '09 at 14:06 1 @Eugene - I think the bigger question here is "what reading is."

I find it hard to believe that anyone could claim to have read the best books on any subject and come here to ask such an elementary question. What books did you read? Titles, please.

– duffymo Dec 30 '09 at 14:09.

Here's a good article explaining the ideas of spring. (By Rod Johnson, the founder of the Spring framework).

You already have some good answers here, I want to address a couple specific questions you have: The idea of describing classes with setter values and/or constructor parameters seems strange to me. Why do that? Because we can change the properties without recompiling the project?

Is that all what we gain? It does seem weird at first but the point is that the container is in charge of plugging in dependencies for the objects, the objects themselves are not in charge of that. The scope of the objects configured in beans.

Xml is managed by Spring, so we don't have to worry so much about things being instantiated without the right dependencies (as long as the configuration is correct, I have been known to write unit tests to check that the spring configuration is doing what I want it to. ) Then, what objects should we describe in beans. Xml?

All objects or only a few? The kinds of objects described in beans. Xml are mostly components--controllers, services, data access objects, and things that they need like transaction managers, hibernate session factories, data sources, stuff like that.

Domain objects are typically retrieved from data access objects or instantiated directly, because they don't have dependencies on anything but other domain objects (or on utility classes that are even more independent than domain classes).

I think I can take a crack at the question, although I'm not sure that any answer will be satisfactory. The easy answer is that Spring is combination of technologies: dependency injection, which uses the Hollywood principle to help you keep interface and implementation separate; aspect oriented programming, which isolates cross cutting concerns into modules that you can apply declaratively. The "hello world" of AOP is logging, but it's all over Spring (e.g. Transactions, dynamic proxies for remoting, security, etc. ) Think servlet filters and you'll have the idea; libraries to help with common tasks like persistence (JDBC, iBatis, JDO, JPA, etc. ), remoting (RMI, HTTP, web services), asynch messaging (message driven POJOs), validating and binding, web MVC (Spring or Struts), utilities like e-mail, scheduling, security, etc.But the deeper answer is that you're getting the benefit of Rod Johnson's experience as a consultant on Java EE projects.

He distilled what worked for him on his gigs into Interface 21/Spring, and now you can have the benefit of all that for free. The Spring team writes code that is designed, tested, and follows standards more rigorously than anything I'll ever write.(Imagine Juergen Hoeller browbeating Rod Johnson because his code didn't meet the standard prior to check-in.) I can count on their framework code when I use it and concentrate on my business problem. I'm not writing boiler plate code again and again.

For me, Spring is more about an architectural template that acts as a guide for creating web apps. Some people might say that it's over-engineered, and for certain problems they're correct, but for the kind of problems that I'm faced with on a regular basis Spring is just the ticket. As for the subquestions: What advantages do we have when using dependency injection frameworks?

Objects don't have to be responsible for managing their dependencies. Spring's application context is really just a big Factory Pattern from the GoF. It encourages you to design to an interface so you can change the implementation as needed.

Your persistence interface might use a JDBC implementation today, you might decide to auto generate a proxy to manage its transactional behavior. None of the client code has to change if you code to an interface. The idea of describing classes with setter values and/or constructor parameters seems strange to me.

Why do that? Because we can change the properties without recompiling the project? Is that all what we gain?

Strange? You don't use properties or constructors in your code? You do it because that's the way most Java classes are written.

Spring merely uses those mechanisms as a way to provide dependencies to the class. Then, what objects should we describe in beans. Xml?

All objects or only a few? Only the beans that have dependencies. I still call "new" for objects that are local to a particular method.

They are created, used, and garbage collected in method scope. Those need not be under Spring's control.

I cannot tell your answer covers all my sub-questions, but still it was interesting to read it. +1 – EugeneP Dec 30 '09 at 14:45 See if the additions are better. – duffymo Dec 30 '09 at 14:58.

Opinion: Figure out what problem you try to solve with DI and take a framework that fits best. Spring could add to much complexity for your problem. (One of the first articles about DI by Martin Fowler.

I think the term DI was coined in this article. ).

Here's a good video given by Bob Lee and two of his under studies about Guice (Guice is a dependency injection framework like Spring). The first 10 or so minutes are about why Guice (or dependency injection) would be better than the alternative (Factories) so it's not all just about Guice.

I suggest you either find an experienced co-worker who is willing to help you, or invest some more effort in reading those books, or otherwise follow a course. In any case, there is no 'simple answer' to your question.

Dependency injection is a workaround for missing virtual classes! NB: if you don't know what virtual classes are, please refer to "Virtual classes, anyone? ".

The horror of C++ multiple virtual inheritance will be with me forever. I like that article, but you need a new name. DI frameworks now use annotations so they are almost indistinguishable from a language feature--until two different frameworks collide and the illusion is shattered.

– Ken Fox Dec 30 '09 at 22:17.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.