wood burning stoves 2.0*
The moose likes Spring and the fly likes Understanding DI Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Understanding DI" Watch "Understanding DI" New topic
Author

Understanding DI

Russell Grantly
Greenhorn

Joined: Feb 15, 2012
Posts: 3
Hello everyone !!!

I just started learning Spring, I understood what DI is and practiced few examples in Eclipse. However, few of the things are not clear to me.

How the implementation of a collaborating class affects the code and increases complexity ?

For example, we should not instantiate Address class inside Employee class. Why ?
How does the implementation change in Address class affects Employee class ?

I am eagerly waiting for an explanation.

Thanks a million in advance.

Russell
Russell Grantly
Greenhorn

Joined: Feb 15, 2012
Posts: 3
Russell Grantly wrote:Hello everyone !!!

I just started learning Spring, I understood what DI is and practiced few examples in Eclipse. However, few of the things are not clear to me.

How the implementation of a collaborating class affects the code and increases complexity ?

For example, we should not instantiate Address class inside Employee class. Why ?
How does the implementation change in Address class affects Employee class ?

I am eagerly waiting for an explanation.

Thanks a million in advance.

Russell
Can someone please help me with this ?
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2431
    
  28

In most applications, you usually have a set of core classes that get used everywhere. For example, let's say you are building a MVC application, and you have neatly divided your classes into a database layer (that does database calls), a service layer (that has business logic) and a view layer(that interacts with user). What you will end up having is the database layer will have some DOA classes that will be used by several service classes. Also, the service classes will be used by several view classes. Now, without DI, changing how your class at database layer will be initialized will have a ripple effect on all the classes in layer above it


So, let's say take a simple example. You have a PersonDAO at the DAO layer. Then you have 2 services, ManagePersonService and ManageOrganizationService in the service layer that needs PersonDAO. Then at the view layer you have 4 actions, AddPersonAction, RemovePersonAction, UpdatePersonAction, and UpdateOrganizationAction. So, let's say you don;t have DI and each Service is responsible for creating an instance of the DAO when it needs it. So, you have 2 places where DAO is initialized. Now, let's say you have a change that requires you to pass a parameter to the DAO during initializing. You end up changing the 2 services, which might result in changing the 4 actions. A horrible ripple effect. Ideally, layers above should be isolated from changes like these

One way to avoid this is use a factory method. Let's say you added a PersonDAOFactory thais responsible for initiializng PersonDAO. All the services will call the factory to get an instance of DAO. So, if you change the init code for PersonDAo, you only change PersonDAOFactory. Fine!. However, what happens if you need to add a paremeter to the initialization, or let's say you need 2 instances of the same DAO. Now again, you end up changing your services. Boo! You didn;t really solve the problem

Enter DI. Using DI, the framework is responsible for all initialization. In case of Spring, all the initialization parameters are in the Spring XML file. Spring will initialize the DAO, services and actions, and will do the "wiring"; ie give an instance of DAO class to the service class. The services are completely oblivious to how the DAO is instantiated. If you need changes in the init code, all you do is change the configuration of your framework. No more ripple effects.
Russell Grantly
Greenhorn

Joined: Feb 15, 2012
Posts: 3
Jayesh A Lalwani wrote:In most applications, you usually have a set of core classes that get used everywhere. For example, let's say you are building a MVC application, and you have neatly divided your classes into a database layer (that does database calls), a service layer (that has business logic) and a view layer(that interacts with user). What you will end up having is the database layer will have some DOA classes that will be used by several service classes. Also, the service classes will be used by several view classes. Now, without DI, changing how your class at database layer will be initialized will have a ripple effect on all the classes in layer above it


So, let's say take a simple example. You have a PersonDAO at the DAO layer. Then you have 2 services, ManagePersonService and ManageOrganizationService in the service layer that needs PersonDAO. Then at the view layer you have 4 actions, AddPersonAction, RemovePersonAction, UpdatePersonAction, and UpdateOrganizationAction. So, let's say you don;t have DI and each Service is responsible for creating an instance of the DAO when it needs it. So, you have 2 places where DAO is initialized. Now, let's say you have a change that requires you to pass a parameter to the DAO during initializing. You end up changing the 2 services, which might result in changing the 4 actions. A horrible ripple effect. Ideally, layers above should be isolated from changes like these

One way to avoid this is use a factory method. Let's say you added a PersonDAOFactory thais responsible for initiializng PersonDAO. All the services will call the factory to get an instance of DAO. So, if you change the init code for PersonDAo, you only change PersonDAOFactory. Fine!. However, what happens if you need to add a paremeter to the initialization, or let's say you need 2 instances of the same DAO. Now again, you end up changing your services. Boo! You didn;t really solve the problem

Enter DI. Using DI, the framework is responsible for all initialization. In case of Spring, all the initialization parameters are in the Spring XML file. Spring will initialize the DAO, services and actions, and will do the "wiring"; ie give an instance of DAO class to the service class. The services are completely oblivious to how the DAO is instantiated. If you need changes in the init code, all you do is change the configuration of your framework. No more ripple effects.


Thank you Jayesh for a detailed explanation.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Understanding DI