CSC/ECE 517 Fall 2010/ch5 5e dr: Difference between revisions
No edit summary |
|||
(8 intermediate revisions by 2 users not shown) | |||
Line 6: | Line 6: | ||
Every enterprise application involves handful number of objects that work together to achieve some purpose. These objects are coupled with each other and work in collaboration, making the classes highly dependent. However, creating such code involving highly coupled classes defeats an important tenet of Object oriented design- ‘loose coupling’. Loose coupling means that objects should have the minimum number of dependencies, which makes the code easy to understand, modify and debug. It also allows for greater code reusability and improves the maintainability.[http://www.codeproject.com/KB/architecture/DependencyInjection.aspx] This drive to decouple the code from its highly dependent objects leads to the concept of Dependency Injection. | Every enterprise application involves handful number of objects that work together to achieve some purpose. These objects are coupled with each other and work in collaboration, making the classes highly dependent. However, creating such code involving highly coupled classes defeats an important tenet of Object oriented design- ‘loose coupling’. Loose coupling means that objects should have the minimum number of dependencies, which makes the code easy to understand, modify and debug. It also allows for greater code reusability and improves the maintainability.[http://www.codeproject.com/KB/architecture/DependencyInjection.aspx] This drive to decouple the code from its highly dependent objects leads to the concept of Dependency Injection. | ||
= Definition = | == Definition == | ||
The basic concept of Dependency Injection(DI) is that you do not create the objects themselves, but describe how they should be created. It is one of the more popular design paradigms known today, by which the objects define their dependencies, i.e. the objects or classes they work with. DI pattern provides better a software design that makes the code cleaner, since the object doesn’t need to look for other components it works with, or know their location and class.[http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators] | The basic concept of Dependency Injection(DI) is that you do not create the objects themselves, but describe how they should be created. It is one of the more popular design paradigms known today, by which the objects define their dependencies, i.e. the objects or classes they work with. DI pattern provides better a software design that makes the code cleaner, since the object doesn’t need to look for other components it works with, or know their location and class.[http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators] | ||
It facilitates the design of applications, using a framework that links the components, instead of the components linking themselves. | It facilitates the design of applications, using a framework that links the components, instead of the components linking themselves. | ||
Line 12: | Line 12: | ||
In other words, Dependency Injection, also known as Inversion Of Control(IoC), transfers the responsibility to locate and create the objects to the framework or the container which supports plug-n-play implementation, by injecting the dependencies into your code. | In other words, Dependency Injection, also known as Inversion Of Control(IoC), transfers the responsibility to locate and create the objects to the framework or the container which supports plug-n-play implementation, by injecting the dependencies into your code. | ||
= Features of Dependency Injection = | == Features of Dependency Injection == | ||
Main features of Dependency Injection Framework are: | Main features of Dependency Injection Framework are: | ||
* Better Design Pattern - Supports good Object-Oriented Design. | * Better Design Pattern - Supports good Object-Oriented Design. | ||
Line 33: | Line 33: | ||
Let us consider a simple example to understand the basic idea of DI. | Let us consider a simple example to understand the basic idea of DI. | ||
Suppose we have an Employee class which depends on the Department object. We need some Assembler (DI Framework) to instantiate the Department field of Employee class. Rather than Employee class creating this object for itself, it will delegate this task of instantiation to any framework selected from above. To do this, it uses configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section | Suppose we have an Employee class which depends on the Department object. We need some Assembler (DI Framework) to instantiate the Department field of Employee class. Rather than Employee class creating this object for itself, it will delegate this task of instantiation to any framework selected from above. To do this, it uses configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 3]. | ||
'''''Employee.java''''' | '''''Employee.java''''' | ||
Line 351: | Line 351: | ||
* It makes the code more readable. | * It makes the code more readable. | ||
Disadvantages are | |||
* | * A developer cannot understand the code easily as there is an abstraction layer which performs the initializing and instantiation of objects. | ||
* | * Developers need to have a certain level of expertise in coding such design patterns. | ||
= References and Notes = | = References and Notes = | ||
[1] [Spring | [1] [http://www.amazon.com/Spring-Action-Craig-Walls/dp/1932394354 Walls, C.,Briedenbach, R. ''Spring in Action'' Manning]<br> | ||
[2] [Java Development | [2] [http://www.amazon.com/Professional-Java-Development-Spring-Framework/dp/0764574833 Johnson, R., Hoeller, J., Arendsen, A. ''Professional Java Development with Spring Framework'' Wrox]<br> | ||
[3] [http://www.springsource.org/ Spring Framework]<br> | [3] [http://www.springsource.org/ Spring Framework]<br> | ||
[4] [http://www.opensymphony.com/xwork/ Xwork]<br> | [4] [http://www.opensymphony.com/xwork/ Xwork]<br> | ||
[ | [5] [http://static.springsource.org/spring/docs/2.5.x/reference/aop.html Aspect Oriented Programming]<br> | ||
[ | [6] [http://en.wikipedia.org/wiki/Circular_dependency Circular Dependency]<br> | ||
External Links | =External Links= | ||
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling]<br> | [1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling]<br> | ||
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection]<br> | [2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection]<br> | ||
Line 374: | Line 371: | ||
= Further Reading = | = Further Reading = | ||
[1] [Dependency Injection in .NET | [1] [http://www.manning.com/seemann/ Seemann, M. ''Dependency Injection in .NET'' Manning]<br> | ||
[2] [Dependency Injection | [2] [http://www.manning.com/prasanna/ Prassanna, D. ''Dependency Injection'' Manning]<br> | ||
[3] [http://www.developer.com/net/csharp/article.php/3722931/Dependency-Injection-with-SpringNet.htm Dependency Injection with Spring .NET] <br> | [3] [http://www.developer.com/net/csharp/article.php/3722931/Dependency-Injection-with-SpringNet.htm Dependency Injection with Spring .NET] <br> | ||
[4] [http://needle.rubyforge.org/api/ Dependency Injection in Ruby] | [4] [http://needle.rubyforge.org/api/ Dependency Injection in Ruby] | ||
[5] [http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc ]<br> | [5] [http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc ]<br> |
Latest revision as of 23:55, 3 November 2010
Dependency Injection
Overview
Every enterprise application involves handful number of objects that work together to achieve some purpose. These objects are coupled with each other and work in collaboration, making the classes highly dependent. However, creating such code involving highly coupled classes defeats an important tenet of Object oriented design- ‘loose coupling’. Loose coupling means that objects should have the minimum number of dependencies, which makes the code easy to understand, modify and debug. It also allows for greater code reusability and improves the maintainability.[1] This drive to decouple the code from its highly dependent objects leads to the concept of Dependency Injection.
Definition
The basic concept of Dependency Injection(DI) is that you do not create the objects themselves, but describe how they should be created. It is one of the more popular design paradigms known today, by which the objects define their dependencies, i.e. the objects or classes they work with. DI pattern provides better a software design that makes the code cleaner, since the object doesn’t need to look for other components it works with, or know their location and class.[2] It facilitates the design of applications, using a framework that links the components, instead of the components linking themselves.
In other words, Dependency Injection, also known as Inversion Of Control(IoC), transfers the responsibility to locate and create the objects to the framework or the container which supports plug-n-play implementation, by injecting the dependencies into your code.
Features of Dependency Injection
Main features of Dependency Injection Framework are:
- Better Design Pattern - Supports good Object-Oriented Design.
- Clean Code- Eliminates the need of looking up code from the application.
- Reuse - Promotes better code reusability.
- Loose Coupling- Objects are loosely coupled using DI
- Simple- It is very simple to implement, just need to inject the dependencies of any object.
- Maintainable- It is very easy to reconfigure and maintain in case of any future changes.
- More Testable- It makes it very easy to test the code, as objects get instantiated with values using configuration files.
Dependency Injection Frameworks
Dependency Injection requires a framework that helps the developer to declare the dependencies, to locate, instantiate, and initialize the components or the objects. A developer has many available frameworks to him:
- Spring Framework – A light weight container, most widely used for DI and very large framework, which includes a lot many other features like Aspect Oriented, framework, container, etc. along with Dependency Injection.[3]
- XWork - It is a standalone framework and mostly works in conjunction with Webworks. It is a highly effective command pattern framework that provides a lot of features for DI.[4]
- Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[5]
- PicoContainer - It is a highly focused DI framework available.[6]
- Hivelogic – Another DI framework to inject dependencies.[7]
Example of Dependency Injection Framework
Let us consider a simple example to understand the basic idea of DI. Suppose we have an Employee class which depends on the Department object. We need some Assembler (DI Framework) to instantiate the Department field of Employee class. Rather than Employee class creating this object for itself, it will delegate this task of instantiation to any framework selected from above. To do this, it uses configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the section 3.
Employee.java package myPackage; public class Employee { //dependent object ‘dept' private Department dept; public void Employee( ){ } setDepartment(dept){ this.dept=dept; } }
Department.java package myPackage; public class Department { private String name; public String getName(){ return name; } public void setName(String name){ this.name=name; } }
The framework will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object. It will form an Employee object with a Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where the binding of beans is done as follows:
ApplicationContext.xml <beans> <bean id="employee" class=" myPackage .Employee.java"> <property name="name " ref="yetAnotherBean"/> </bean> <bean id="department" class=" myPackage .Department.java"> <property name="name" value="Java"/> </bean> </beans>
thereby creating the dependency diagram as:
Here we can see that, the classes themselves do not create their own instances, but it is the framework that does this job for them, making the code cleaner, reusable and loosely coupled. In future if one wants to add on, delete or modify any of the dependent objects, one only needs to update the configuration file. There is no need to look up the code all over again to find the class’s dependent objects. One can make modifications to the lines of code creating instances, which may be,
// used everywhere in code without Dependency Injection. Department dept=new Department ();
Thus it makes our code configurable and maintainable. Let us now move on and see some more examples to understand the different types of injections available within different frameworks.
Types of Dependency Injection
There are a number of Dependency Injection variants that exists to allow the developer to implement and write loosely coupled code. The dependencies can be injected in various forms like:
- Type 1- Interface Injection
- Type 2- Setter Injection
- Type 3- Constructor Injection
Type 1- Interface Injection
Interface injection is a technique to add the dependency for interfaces in components at run time. The components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using the Avalon framework.
For example, we have an ApplicationDAO interface, while AccountApplicationDAO and CustomerApplicationDAO are the classes implementing ApplicationDAO,
ApplicationDAO.java package myPackage; public interface ApplicationDAO { void getEntity(); }
AccountApplicationDAO.java package myPackage; public class AccountApplicationDAO implements ApplicationDAO { void getEntity(){ //get all accounts. } }
CustomerApplicationDAO.java package myPackage; public class CustomerApplicationDAO implements ApplicationDAO { void getEntity() { //get all customers. } }
We also have ApplicationService interface, which depends on the ApplicationDAO interface. The ApplicationServiceImpl class implements the ApplicationService inteface, which in turn implements the ApplicationDAO interface, provided by the container.
ApplicationService.java package myPackage; public interface ApplicationService { getEntity(ApplicationDAO applicationDAO); }
ApplicationServiceImpl.java package myPackage; public class ApplicationServiceImpl implements ApplicationService { ApplicationDAO applicationDAO; validateEntity (ApplicationDAO applicationDAO) { this. applicationDAO= applicationDAO; applicationDAO.getEntity(); //code to validate the Entity (Account/Customer),as per the configuration in xml file. } }
Now, our main program will get the interface dependency from the container, which uses configuration file for look up,
package myPackage; public class MyClass { public static void main(string[] args) { // Get the correct dependency based on configuration file ApplicationDAO dependencyDAO = getDependecny(); // Create our applicationServiceImpl class and inject the dependency ApplicationServiceImpl applicationServiceImpl = new ApplicationServiceImpl(); // call validateEntity() ((ApplicationService)applicationServiceImpl).validateEntity(dependencyDAO); } public static ApplicationDAO getDependency() { string implementClass = System.Configuration.ConfigurationManager.AppSettings["selectedClass"]; Type type = System.Type.GetType(implementClass); ApplicationDAO applicationDAO = (ApplicationDAO)Activator.CreateInstance(type); return applicationDAO; } }
The Configuration File that will be used by MyClass file to lookup the dependency configurations will be of type:
App.Config <?xml version="1.0" encoding="utf-8" ?> <configuration> <appSettings> <add key=" selectedClass " value="myPackage. AccountApplicationDAO " /> </appSettings> </configuration>
In this example, validateEntity() in ApplicationServiceImpl will call getEntity() using ApplicationDAO reference. The getEntity() that is invoked will actually depend on the dependency that is injected via the configuration file.
Type 2- Setter Injection
Dependency can be injected using the setter method of a class. If a class is dependent on another class or object instances, then the dependency should be declared as a state(variable) of the class and the class should have a setter method for it. The dependencies are set onto public attributes of the object in need. One of the primary motive for using setters, is supporting dependency injection without having to modify the constructor of a legacy class. Another use is to allow the creation of expensive resources or services as late as possible and only when needed, which is an edge over the Constructor Injection, which we will see in few moments.
Let us consider an example of Setter injection by using Spring Framework.[3] Before using Spring, let us study some basic features of Spring. We will cover only a brief overview of the Spring Framework.
- Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[8], MVC, etc.
- Spring Framework supports both Setter Injection and Constructor Injection, but not Interface Injection. Spring jars that can be included are :
- spring-beans.jar
- spring-core.jar
- Packages that provide Spring Frameworks’s IoC container are:
- org.springframeworks.beans
- org.springframeworks.context
Now let us see Setter injection using the Spring framework.
The example below includes a class, DoctorService. The DoctorService class needs a data-access object for communicating with the database. Assume, the PrescriptionDAO ("order data-access object") is the class on which DoctorService depends.
DoctorService.java package myPackage; public class DoctorService { private PrescriptionDAO prescriptionDAO; //empty constructor public DoctorService () {} public PrescriptionDAO getPrescriptionDAO() { return this.prescriptionDAO; } //setter for prescriptionDAO public setPrescriptionDAO(prescriptionDAO) { this.prescriptionDAO = prescriptionDAO; } //business logic that actually uses prescriptionDAOto access its variables and methods. public void print() { System.out.println(“prescription: “+prescriptionDAO.prescription); System.out.println(“dose: “+prescriptionDAO.dose); } }
PrescriptionDAO.java package myPackage; public class PrescriptionDAO { private String prescription; private int dose; public PrescriptionDAO(){} public String getPrescription () { return this.prescription; } public void setPrescription(String prescription) { this. prescription = prescription; } }
Here, the invoking object is responsible for setting the PrescriptionDAO dependency. There is no code inside the class that is creating new instance of PrescriptionDAO. This is because this task will be performed by the Spring container, by looking for dependencies of DoctorService inside applicationContext.xml file.
The Spring framework uses a setter method to create this dependent object. Note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
ApplicationContext.xml <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"> <bean id="doctorServiceId " class="myPackage.DoctorService"> <property name=" prescriptionDAO "><ref bean=" prescriptionDAOId "/></property> </bean> <bean id=" prescriptionDAOId" class=" myPackage.PrescriptionDAO "> <property name="prescription" value="Take medicine regularly."/> <property name="dose" value="3"/> </bean> </beans>
Now, Client is a class that is used to instantiate the Spring Container and retrieve the bean definitions from inside.
MyClient.java package myPackage; import java.io; import org.springframework.beans.factory.*; import org.springframework.beans.factory.xml.*; import org.springframework.core.io; public class MyClient { public static void main(String args[]) { Resource res=new ClassPathResource(“./myPackage/ ApplicationContext.xml”); BeanFactory factory =new XmlBeanFactory(res); //” doctorServiceId” is the same id defined in ApplicationContext.xml DoctorService doctorService= (DoctorService) factory.getBean(“doctorServiceId”); } }
Here, first the path for the ApplicationContext is specified, and then this file is used as a resource by the container. The BeanFactory container uses the xml file to access the bean defined inside the configuration file.
However, Setter Injection unnecessarily adds to the abstraction. The developer needs to know which dependencies are needed when. On the other hand, it can save on modifying a lot of legacy code when introducing new methods, and can provide a performance boost if the dependency is expensive or not easily accessible.
Type 3- Constructor Injection
Constructor Injection is the DI technique of passing an object's dependencies to its constructor. It addresses the most common scenario where a class requires one or more Dependencies, and no reasonable local defaults are available.
Constructor Injection addresses this scenario very well, because it guarantees that the Dependency is always present. If the depending class absolutely cannot function without the Dependency, such a guarantee is valuable. Constructor-injection enforces the order of initialization and prevents circular dependencies [9]. On the other hand, with Setter injection, it is not clear, in which order things need to be instantiated. Apart from the guaranteed injection, this pattern is also very easy to implement.
Continuing with the example mentioned above, we can implement the same using constructor injection as follows,
DoctorService.java package myPackage; public class DoctorService { private PrescriptionDAO prescriptionDAO; // constructor for instantiatng prescriptionDAO public DoctorService (prescriptionDAO) { this.prescriptionDAO = prescriptionDAO; } //business logic that actually uses prescriptionDAOto access its variables and methods. public void print() { System.out.println("prescription:" +prescriptionDAO.prescription); System.out.println("dose: "+prescriptionDAO.dose); } }
In the example, you must have noticed the parametrized constructor which Spring framework uses to instantiate the value of prescriptionDAO. Now, the question is- how Spring container will come to know whether it has to use Constructor injection or Setter Injection? Tags inside the <bean> tag will specify this:
- <property> tag is used for Setter Injection
- <constructor-arg> is used for Constructor Injection.
ApplicationContect.xml for Constructor injection will be:
ApplicationContect.xml <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"> <bean id="doctorServiceId " class="myPackage.DoctorService"> <constructor-arg> <ref bean=" prescriptionDAOId "/> </constructor-arg> </bean> <bean id=" prescriptionDAOId" class=" myPackage.PrescriptionDAO "> <property name="prescription" value="Take medicine regularly."/> <property name="dose" value="3"/> </bean> </beans>
Definitions for PrescriptionDAO.java and MyClient.java will remain the same. The advantage of using Constructor Injection is that it can create the objects at the time of instantiation itself. Hence it guarantees the developer, that the objects will definitely get created and no exception will be raised.
However, unlike Setter injection it won’t allow changes to the dependency, once it is created.
Advantages and Disadvantages
Advantage of using Dependency injection are
- Clean code which helps to separate out the logic and the instantiation modules.
- It is also easy to maintain the code with the use of configuration files where we can make changes in future whenever required.
- It is very easy to test the code using Dependency Injection.
- It makes the code more readable.
Disadvantages are
- A developer cannot understand the code easily as there is an abstraction layer which performs the initializing and instantiation of objects.
- Developers need to have a certain level of expertise in coding such design patterns.
References and Notes
[1] Walls, C.,Briedenbach, R. Spring in Action Manning
[2] Johnson, R., Hoeller, J., Arendsen, A. Professional Java Development with Spring Framework Wrox
[3] Spring Framework
[4] Xwork
[5] Aspect Oriented Programming
[6] Circular Dependency
External Links
[1] Dependency Injection for Loose Coupling
[2] Dependency injection
[3] Excalibur Apache Avalon
[4] PicoContainer
[5] Hivelogic
Further Reading
[1] Seemann, M. Dependency Injection in .NET Manning
[2] Prassanna, D. Dependency Injection Manning
[3] Dependency Injection with Spring .NET
[4] Dependency Injection in Ruby
[5] [10]