Dependency Injection - what is the difference between these two codes? [closed] - oop

Question

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I have been trying to understand dependency injection and I have been making progress but
I will like to know the benefit/difference/importance of these code. They look the same but different approach
//dependency injection - (as was claimed)
Customer customer = new Customer(10);
IOrderDAO orderDAO = new OrderDAO();
customer.setOrderDAO(orderDAO);
customer.getOrdersByDate();
OR
//Unknown Pattern - Please what pattern is this?
Customer customer = new Customer(10);
IOrderDAO orderDAO = new OrderDAO();
orderDAO.getOrderByDate(customer.id);
What's wrong with the second approach?
Thanks.

Answer 1

Neither one looks like dependency injection to me; there shouldn't be calls to new.
Dependency injection is done by a bean factory that's wired with all the dependencies. It instantiates the beans and gives them their dependencies.
I see no bean factory here at all. It's a long way to dependency injection.
The Customer gets the OrderDAO in the first example using the setter. The first one says that the Customer has to expose persistence methods in its API. It's responsible for saving its Orders. I'd say it's a poor separation of concerns, because now Customers have to know about Orders.
The second one keeps Customer separate from OrderDAO. You pass a Customer ID to the OrderDAO and have it save Orders on that Customer's behalf. I think it's a better separation of concerns.
But neither one is a good example of dependency injection.
The first and best description of DI came from Martin Fowler. I'd recommend that you read this carefully:
http://martinfowler.com/articles/injection.html
It's eight years old, but still spot on.

Answer 2

Neither of them is proper dependency injection example. Those are rather examples of data access patterns.
The first one is an example of active record pattern. Setting orderDAO as a dependency for customer entity we could call property or setter injection.
The second example could be repository pattern. Dependency pattern here would be method injection, which translates to common invoking method with some parameters (parameters here are dependencies for method).
Good way to start learning DI pattern would be reading this book. There are also many online resources like those videos:
http://www.youtube.com/watch?v=RlfLCWKxHJ0
http://www.youtube.com/watch?v=-FRm3VPhseI&feature=relmfu
http://www.youtube.com/watch?feature=player_embedded&v=hBVJbzAagfs
I would also recommend looking for Dependency Inversion Principle in google (it's not the same as dependency injecion).

Answer 3

It's an odd example, but the first one demonstrates what a dependency injection container would do and the second one demonstrates one object passing an argument to another object. The first embeds its dependencies as instance variables of the calling class; the second is more procedural in nature. Neither is wrong, per se. It depends on how complex your dependencies are and how you want to manage code.
Looking just at the injector code you provided, it's not immediately obvious why you'd ever want to use dependency injection. But consider a more complex (and more typical) example for a moment.
CustomerService:
public class CustomerService implements ICustomerService {
private IOrderDAO orderDao;
public void setOrderDAO(IOrderDAO orderDao) {
this.orderDao = orderDao;
}
public Order getOrderByDate(Integer customerId, Date date) {
return this.orderDao.findOrderByDate(customerId, date);
}
}
OrderDAO (default implementation):
public OrderDAO implements IOrderDAO {
private javax.sql.DataSource dataSource;
public void setDataSource(javax.sql.DataSource dataSource) {
this.dataSource = dataSource;
}
public Order findOrderByDate(Integer customerId, Date date) {
...
}
}
StubOrderDAO (stub implementation):
public StubOrderDAO implements IOrderDAO {
public Order findOrderByDate(Integer customerId, Date date) {
return new HardCodedOrder(); // this class would extend or implement Order
}
}
At runtime, instances of CustomerService won't have any idea which implementation of IOrderDAO is being used. That means that you could very easily, for instance, bootstrap a unit test for CustomerService by initializing it with StubOrderDAO (which always returns a hard-coded customer). Likewise, your DataSource implementation may vary (either a mock data source or one which is different in different runtime environments).
So an injector intended for production use might look like:
// instantiate
CustomerService service = new CustomerService();
OrderDAO dao = new OrderDAO();
javax.sql.dataSource dataSource = jndiContext.lookup("java:comp/env/MyDataSource");
// initialize
dao.setDataSource(dataSource);
service.setOrderDAO(dao);
return service;
Whereas an injector for using a local (test) data source might look like:
// instantiate
CustomerService service = new CustomerService();
OrderDAO dao = new OrderDAO();
javax.sql.dataSource dataSource = new DriverManagerDataSource("jdbc:sqlserver:yadayada...", "myUsername", "myPassword");
// initialize
dao.setDataSource(dataSource);
service.setOrderDAO(dao);
return service;
And an injector for an integration test might look like:
// instantiate
CustomerService service = new CustomerService();
OrderDAO dao = new StubOrderDAO();
// initialize
service.setOrderDAO(dao);
return service;
So it's essentially a way to implement good layering and separation of concerns, i.e. the way you access the database is independent of how you access the data to create the domain model, and both are independent of any aggregation or business logic processing you'd do in CustomerService (not shown here for sake of brevity).
Does that make more sense?

Answer 4

Don't confuse inversion of control with dependency injection (as another answer did). I describe dependency injection and IoC here: http://www.codeproject.com/Articles/386164/Get-injected-into-the-world-of-inverted-dependenci
//dependency injection - (as was claimed)
Customer customer = new Customer(10);
IOrderDAO orderDAO = new OrderDAO();
customer.setOrderDAO(orderDAO);
customer.getOrdersByDate();
No. I would not call that DI. I would go as far as calling it badly written code. The customer should not be aware of the persistance layer which setOrderDAO(orderDAO) forces it to be. It breaks the single responsibility principle since the customer also have to take care of the orders.
//Unknown Pattern - Please what pattern is this?
Customer customer = new Customer(10);
IOrderDAO orderDAO = new OrderDAO();
orderDAO.getOrderByDate(customer.id);
It's not specific pattern, but better code since there is no coupling between the customer and the orderDao.