1 Replies - 314 Views - Last Post: 15 July 2019 - 01:04 PM

#1 NecroWinter   User is offline

  • D.I.C Regular

Reputation: 38
  • View blog
  • Posts: 348
  • Joined: 21-October 11

Basic question about Dependency Injection

Posted 12 July 2019 - 11:26 AM

I understand interfaces quite well, I use/create them at work every day. But I don't entirely understand the point of dependency injection.

Interface A = new Impl();




In this case, "new Impl()" is hardcoded. But by putting new Impl in beans.xml, it seems that all we're doing is switching the hardcoding from a java class to an xml file. So I'm wondering, what exactly is the benefit?? Legitimately wondering

A second question:

Let's say we have this pseudo code


Interface doSomething;

if (file.exists){
doSomething = new writeToFile();
} 
else {
doSomething = new createFile();
}

doSomething.doAction();




I do this sort of pattern all the time. How exactly would you do something like this with the xml file method?

Is This A Good Question/Topic? 0
  • +

Replies To: Basic question about Dependency Injection

#2 ndc85430   User is online

  • I think you'll find it's "Dr"
  • member icon

Reputation: 981
  • View blog
  • Posts: 3,868
  • Joined: 13-June 14

Re: Basic question about Dependency Injection

Posted 15 July 2019 - 01:04 PM

View PostNecroWinter, on 12 July 2019 - 07:26 PM, said:

But I don't entirely understand the point of dependency injection.


There are a couple of reasons why it's a good thing. The first is that it helps loosen coupling. When your class instantiates its dependencies, it needs to know how to do that - that is, it needs all the information to call the constructor of the dependency and where to get it from. Does the class with the dependency really need to care about all that? The answer is likely no, because any changes you make to the dependency are naturally going to affect that class that uses it. It risks causing bugs and more importantly, makes the software harder to change because these changes are going to ripple through the system.

The second reason is helping to make your software more easily testable, because you then have the ability to pass in other implementations. For example, you have a class whose job is to write output somewhere and in the production code you're writing to standard out. If you've hardcoded said class to use System.out, how are you going to test the correct stuff was written? Maybe there's a way to capture the output stream, but that might be complex (having to remember to reset the stream after tests and whatever else). Instead, you make your class take some kind of Writer and the tests can use, say, a StringWriter that you can easily read from and assert on, while the production code uses whatever can write to standard out. Read about test doubles if you've not used them before.

Quote

But by putting new Impl in beans.xml


It sounds like you're using Spring and I can't comment on your other questions, but only want to point out that Spring is not the only way to DI. Our approach (NB: I'm on a Scala team, but we'd be doing the same if we were doing Java or anything else!) is to wire up the dependencies manually (i.e. by writing the lines of code to invoke the constructors for the classes and pass them to whatever classes need them). This might seem like boilerplate, but the advantage is that compilation will fail if things haven't been wired up correctly.

This post has been edited by ndc85430: 17 July 2019 - 08:56 AM
Reason for edit:: Fixed broken link.

Was This Post Helpful? 1
  • +
  • -

Page 1 of 1