-1

I have a class

@Component
public class MessageServiceHelper {
    @Autowired
    private MessageService messageService;

    public boolean sendMessage(String text){
        return messageService.sendMessage(text);
    }
    public MessageService getMessageService() {
        return messageService;
    }

    public void setMessageService(MessageService messageService) {
        this.messageService = messageService;
    }
}

so here I am autowiring messageService, so that whenever the object ob MessageServiceHelper is instantiated then it will automatically inject dependency messageService into MessageServiceHelper. Same thing I can achieve if I have write some other class which will create the instance of MessageService and will call the setter method.

Now here the point can be raised is we have shifted the dependency resolution logic some where else and that code is coupled with the instantiation of MessageService and if some implementation is changed then I will have to change that class but with spring also If I have to change implementation I have to make change in metadata that I have given before.

so here my question is what is different with DI? What is strongest point about DI here?

eatSleepCode
  • 4,427
  • 7
  • 44
  • 93
  • For more information about Dependency Injcection, please take a look at the [dependency-injection](https://stackoverflow.com/tags/dependency-injection/info) tag. – Steven Oct 15 '15 at 11:06

2 Answers2

1

In short, the metadata change is desirable which enables configuration of a higher layer of abstraction rather than change in the application code. The configurable higher layer is then reusable and your lower layer of application code is easily testable. Dependency injection is one of the very old core design principles featuring in famous SOLID design principles. This design principle has featured into lots of frameworks out there - Spring being one of the most popular and evangelist of DI in Java world. There are already lots of good articles available to understand the necessity of DI- you can read them on Wikipedia and Microsoft library. And yes, then there are few gem of articles on Martin Fowler's site to understand it in depth here and here.

Shailendra
  • 8,874
  • 2
  • 28
  • 37
0

The point of dependency injection is reuse. Crafting your code correctly you can inject multiple implementations at runtime.

This is particularly useful for unit testing where you want to pass a mock object instead of a real one without modifying the object. By moving the dependency outside of the code and injecting it you can test your code without modifying it.

It also allows a separation of concerns. If the creation of the object is a complex affair you don't have to put that code in the class which uses it. Other code or classes can do the creation and just pass it into your class, which no longer has to worry about the specifics of how it was created. So moving it outside is an advantage. Think of complex objects created using frameworks. Good examples include instantiating a database driver or database session.

There are other specific instances where the reuse is practical but I would say these are the main ones I've seen for web applications and business code.

Sammy
  • 467
  • 3
  • 13