-1

If I follow dependency injection principle for a class design, I should make sure my class does not try to instantiate its dependencies within my class, but rather ask for the object through the constructor.

This way I am in control of the dependencies I provide for the class while unit-testing it. This I understand.

But what I am not sure is does this mean that a good class design which follows dependency injection principle means that its fields should never be initialized inline? Should we totally avoid inline initialization to produce testable code?

EDIT

Which is better 1 or 2?

1

  public class Car {
       private Tire tire = new Tire(); // 
    }

2

public class Car {

   private Tire tire;
   public Car(Tire tire) {
       this.tire = tire
   }
}
DesirePRG
  • 6,122
  • 15
  • 69
  • 114
  • That obviously depends on the types of the fields. It makes no sense to inject "basic" types like `Number`, date related (`java.time`) classes or for example `StringBuilder`, when you only need them in that class. – Tom Sep 30 '17 at 13:22
  • 1
    What exactly do you mean by "inline initialization"? That fields are initialized in the constructor by the class itself or what? – lexicore Sep 30 '17 at 13:22
  • *I should make sure my class does not try to instantiate its dependencies within my class*: Absolutely. Nevertheless, that's exactly what your first snippet does. So you have your answer. The dependency must be provided from the outside of the class. That's clearly not the case of your first snippet. – JB Nizet Sep 30 '17 at 13:28
  • @JBNizet yeah that's clear. But is it always the rule? Does this mean if I see inline initialization in a class it is bad design? – DesirePRG Sep 30 '17 at 13:29
  • 1
    No. Of course not. Dependency injection is a tool, that is appropriate to use in certain situations, and not in others. – JB Nizet Sep 30 '17 at 13:32

2 Answers2

0

In my opinion, In general, if you think that the data field is a dependency, then let the dependency management container should manage it. What counts a dependency and what is not dependency is a tough question, and only you can decide.

For example: if your design of car allows working with different types of Tyres, then it's a dependency. Otherwise, inside a class Car you'll have to work with some kind of TyreFactory, which is not really reasonable.

If you work with DI container, testing the class will be a breeze. You'll have to provide a stub/mock to the class which is obviously a real benefit. So, in your example, if you go with the first solution then, how will you test that your car works with different types of Tyres?

halfer
  • 19,824
  • 17
  • 99
  • 186
Mark Bramnik
  • 39,963
  • 4
  • 57
  • 97
0

No, it surely doesn't mean inline initialization. I'm not a Java user but this term is relevant to many programming languages.

Basically, instead of having your objects creating a dependency or asking a factory object to make one for them, you pass the needed dependencies into the object externally, and you make it somebody else's problem.

public SomeClass() {
    myObject = Factory.getObject();
}

"Dependency Injection" is a 25-dollar term for a 5-cent concept. [...] Dependency injection means giving an object its instance variables. [...].

Dependency injection is basically providing the objects that an object needs (its dependencies) instead of having it construct them itself. It's a very useful technique for testing since it allows dependencies to be mocked or stubbed out.

Any application is composed of many objects that collaborate with each other to perform some useful stuff. Traditionally each object is responsible for obtaining its own references to the dependent objects (dependencies) it collaborates with. This leads to highly coupled classes and hard-to-test code.

A lot of reference from here

Black Mamba
  • 13,632
  • 6
  • 82
  • 105