Possible Duplicates:
What is dependency injection?
What exactly is Spring for?
I want to know What is Spring Framework? Why and when should one use it in Java Enterprise development? The answer would be "A dependency injection framework". All right, what advantages do we have when using dependency injection frameworks? 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 that we gain?
Then, what objects should we describe in beans.xml
? All objects or only a few?
The simplest answers are welcome
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
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. http://code.google.com/p/google-guice/
Here's a good article explaining the ideas of spring. (By Rod Johnson, the founder of the Spring framework)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With