I'he read a lot about this but still i am unclear about the things. We say that DI means injecting dependencies into dependent components at runtime
Q1
What is a dependency ? If these are the objects created at runtime?
If yes, does that mean we are injecting values into variables by creating an object(created by framework i.e instantianting the bean via xml file with setter/constructor injection)
Q2
We do the DI to do work without object intervention?
From Wikipedia, all elements in DI pattern are objects. The dependent object specifies what it needs using interfaces. The injector object decides what concrete classes (instantiated objects) can satisfy the requirement and provide them to the dependent object.
So, that becomes a yes to the second part.
Again from Wikipedia:
The primary purpose of the dependency injection pattern is to allow selection among multiple implementations of a given dependency interface at runtime, or via configuration files, instead of at compile time.
As an example consider a security service that can work different implementations of an Encoder. The different encoding algorithm could include SHA, MD5 and others. The security service only specifies that it needs an instance of "an encoding algorithm". The runtime DI environment then will look to find an object that is providing the interface of Encoder and then injects to the security service. In line with DI, the security service is also taking advantage of Inversion of Control (IoC); i.e. it does not itself decide what implementation to use but it is the DI runtime that takes that decision.
Not a elaborate answer to make it just simpler.
Ques1:
class Dependent {
propertyA = new PropertyA();
propertyB = new PropertyB();
}
Here Dependent is dependent to propertyA and propertyB. Above relation is an example of dependency.
If these are the objects created at runtime? Yes.
If yes....? Yes too
Ques2: Yes.
Detail is included below
Scenario 1:
class Dependent {
DBConnection connection = new OracleConnection();
}
Dependent class is highly coupled. Since there is no way to change the connection unless we change the code. So if customer need MySQLConnection() we will have to change the code and give them another exe/jar.
Scenario 2:
class Dependent {
DBConnection connection = ConnectionFactory.createConnection();
}
This is much better since, ConnectionFactory will be able to read some configuration and create necessary connection.
But still, it raises some difficulty to mock the Dependent class. It is hard to create mock in these scenarios. Then what?
Scenario 3:
class Dependent {
DBConnection connection;
setConnection(DBConnection connection) {
this.connecttion = connection;
}
}
class DependencyInjector {
inject() {
// wire them together every dependent & their dependency!
Dependent dependent = indentiyDepenentSomeSmartWay();
DBConnection connection = indentiyConnectionSomeSmartWay();
dependent.setConnection(connection);
}
}
Our DependencyInjector is a smart class, know all the necessary information! Above Dependent class is clean & simple. It is easy mock them for unit test, configurable using configuration.
Those object creation & coupling is detached!
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