Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T23:55:47Z

Whiteopal: /* Advantages and Disadvantages */

'''Dependency Injection'''

__TOC__
= 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.[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 ==
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.

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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [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'''''
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: 
[[Image:Di_image1.png]]

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[http://static.springsource.org/spring/docs/2.5.x/reference/aop.html], 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. [[image:di_image2.png]] 

'''''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 [http://en.wikipedia.org/wiki/Circular_dependency].
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection 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] [http://www.amazon.com/Spring-Action-Craig-Walls/dp/1932394354 Walls, C.,Briedenbach, R. ''Spring in Action'' Manning] 
[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] 
[3] [http://www.springsource.org/ Spring Framework] 
[4] [http://www.opensymphony.com/xwork/ Xwork] 
[5] [http://static.springsource.org/spring/docs/2.5.x/reference/aop.html Aspect Oriented Programming] 
[6] [http://en.wikipedia.org/wiki/Circular_dependency Circular Dependency] 

=External Links=
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling] 
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection] 
[3] [http://excalibur.apache.org/framework/index.html Excalibur Apache Avalon] 
[4] [http://www.picocontainer.org/ PicoContainer] 
[5] [http://hivelogic.com/ Hivelogic] 

= Further Reading =
[1] [http://www.manning.com/seemann/ Seemann, M. ''Dependency Injection in .NET'' Manning] 
[2] [http://www.manning.com/prasanna/ Prassanna, D. ''Dependency Injection'' Manning] 
[3] [http://www.developer.com/net/csharp/article.php/3722931/Dependency-Injection-with-SpringNet.htm Dependency Injection with Spring .NET] 
[4] [http://needle.rubyforge.org/api/ Dependency Injection in Ruby]
[5] [http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc ]

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T23:50:53Z

Whiteopal: /* Conclusion */

'''Dependency Injection'''

__TOC__
= 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.[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 ==
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.

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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [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'''''
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: 
[[Image:Di_image1.png]]

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[http://static.springsource.org/spring/docs/2.5.x/reference/aop.html], 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. [[image:di_image2.png]] 

'''''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 [http://en.wikipedia.org/wiki/Circular_dependency].
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection 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 is performing initializing and instantiation of objects.
* Developers need to have a certain level of expertise in coding such design patterns.

= References and Notes =
[1] [http://www.amazon.com/Spring-Action-Craig-Walls/dp/1932394354 Walls, C.,Briedenbach, R. ''Spring in Action'' Manning] 
[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] 
[3] [http://www.springsource.org/ Spring Framework] 
[4] [http://www.opensymphony.com/xwork/ Xwork] 
[5] [http://static.springsource.org/spring/docs/2.5.x/reference/aop.html Aspect Oriented Programming] 
[6] [http://en.wikipedia.org/wiki/Circular_dependency Circular Dependency] 

=External Links=
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling] 
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection] 
[3] [http://excalibur.apache.org/framework/index.html Excalibur Apache Avalon] 
[4] [http://www.picocontainer.org/ PicoContainer] 
[5] [http://hivelogic.com/ Hivelogic] 

= Further Reading =
[1] [http://www.manning.com/seemann/ Seemann, M. ''Dependency Injection in .NET'' Manning] 
[2] [http://www.manning.com/prasanna/ Prassanna, D. ''Dependency Injection'' Manning] 
[3] [http://www.developer.com/net/csharp/article.php/3722931/Dependency-Injection-with-SpringNet.htm Dependency Injection with Spring .NET] 
[4] [http://needle.rubyforge.org/api/ Dependency Injection in Ruby]
[5] [http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc ]

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T23:49:52Z

Whiteopal: /* Advantages and Disadvantages */

'''Dependency Injection'''

__TOC__
= 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.[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 ==
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.

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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [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'''''
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: 
[[Image:Di_image1.png]]

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[http://static.springsource.org/spring/docs/2.5.x/reference/aop.html], 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. [[image:di_image2.png]] 

'''''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 [http://en.wikipedia.org/wiki/Circular_dependency].
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection 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 is performing initializing and instantiation of objects.
* Developers need to have a certain level of expertise in coding such design patterns.

= Conclusion =
Hence, Dependency Injection design pattern is good enough to implement in the enterprise applications of large scale, as it helps in reusability, maintainability and testing.

= References and Notes =
[1] [http://www.amazon.com/Spring-Action-Craig-Walls/dp/1932394354 Walls, C.,Briedenbach, R. ''Spring in Action'' Manning] 
[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] 
[3] [http://www.springsource.org/ Spring Framework] 
[4] [http://www.opensymphony.com/xwork/ Xwork] 
[5] [http://static.springsource.org/spring/docs/2.5.x/reference/aop.html Aspect Oriented Programming] 
[6] [http://en.wikipedia.org/wiki/Circular_dependency Circular Dependency] 

=External Links=
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling] 
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection] 
[3] [http://excalibur.apache.org/framework/index.html Excalibur Apache Avalon] 
[4] [http://www.picocontainer.org/ PicoContainer] 
[5] [http://hivelogic.com/ Hivelogic] 

= Further Reading =
[1] [http://www.manning.com/seemann/ Seemann, M. ''Dependency Injection in .NET'' Manning] 
[2] [http://www.manning.com/prasanna/ Prassanna, D. ''Dependency Injection'' Manning] 
[3] [http://www.developer.com/net/csharp/article.php/3722931/Dependency-Injection-with-SpringNet.htm Dependency Injection with Spring .NET] 
[4] [http://needle.rubyforge.org/api/ Dependency Injection in Ruby]
[5] [http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc ]

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T23:46:19Z

Whiteopal:

'''Dependency Injection'''

__TOC__
= 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.[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 ==
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.

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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [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'''''
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: 
[[Image:Di_image1.png]]

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[http://static.springsource.org/spring/docs/2.5.x/reference/aop.html], 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. [[image:di_image2.png]] 

'''''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 [http://en.wikipedia.org/wiki/Circular_dependency].
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection 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.

But the down side of Dependency Injection are that,
* It is not quite easy to understand the code for developers as there seems to be an abstraction layer which is performing initializing and instantiation of objects.
* Moreover, developers should have an expertise in coding such design patterns.

= Conclusion =
Hence, Dependency Injection design pattern is good enough to implement in the enterprise applications of large scale, as it helps in reusability, maintainability and testing.

= References and Notes =
[1] [http://www.amazon.com/Spring-Action-Craig-Walls/dp/1932394354 Walls, C.,Briedenbach, R. ''Spring in Action'' Manning] 
[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] 
[3] [http://www.springsource.org/ Spring Framework] 
[4] [http://www.opensymphony.com/xwork/ Xwork] 
[5] [http://static.springsource.org/spring/docs/2.5.x/reference/aop.html Aspect Oriented Programming] 
[6] [http://en.wikipedia.org/wiki/Circular_dependency Circular Dependency] 

=External Links=
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling] 
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection] 
[3] [http://excalibur.apache.org/framework/index.html Excalibur Apache Avalon] 
[4] [http://www.picocontainer.org/ PicoContainer] 
[5] [http://hivelogic.com/ Hivelogic] 

= Further Reading =
[1] [http://www.manning.com/seemann/ Seemann, M. ''Dependency Injection in .NET'' Manning] 
[2] [http://www.manning.com/prasanna/ Prassanna, D. ''Dependency Injection'' Manning] 
[3] [http://www.developer.com/net/csharp/article.php/3722931/Dependency-Injection-with-SpringNet.htm Dependency Injection with Spring .NET] 
[4] [http://needle.rubyforge.org/api/ Dependency Injection in Ruby]
[5] [http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc ]

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T23:30:21Z

Whiteopal:

'''Dependency Injection'''

__TOC__
= 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.[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 ==
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.

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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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[http://static.springsource.org/spring/docs/2.5.x/reference/aop.html], 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. [[image:di_image2.png]] 

'''''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 [http://en.wikipedia.org/wiki/Circular_dependency].
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection 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.

But the down side of Dependency Injection are that,
* It is not quite easy to understand the code for developers as there seems to be an abstraction layer which is performing initializing and instantiation of objects.
* Moreover, developers should have an expertise in coding such design patterns.

= Conclusion =
Hence, Dependency Injection design pattern is good enough to implement in the enterprise applications of large scale, as it helps in reusability, maintainability and testing.

= References and Notes =
[1] [Spring in Action by Craig Walls, Ryan Briedenbach] 
[2] [Java Development with Spring Framework, by Rod Johnson, Juergen Hoeller, Alef Arendsen, Thomas Risberg, Colin Sampaleanu] 
[3] [http://www.springsource.org/ Spring Framework] 
[4] [http://www.opensymphony.com/xwork/ Xwork] 
[5] [http://static.springsource.org/spring/docs/2.5.x/reference/aop.html Aspect Oriented Programming] 
[6] [http://en.wikipedia.org/wiki/Circular_dependency Circular Dependency] 

=External Links=
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling] 
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection] 
[3] [http://excalibur.apache.org/framework/index.html Excalibur Apache Avalon] 
[4] [http://www.picocontainer.org/ PicoContainer] 
[5] [http://hivelogic.com/ Hivelogic] 

= Further Reading =
[1] [Dependency Injection in .NET by Mark Seemann] 
[2] [Dependency Injection by Dhanji R Prassanna] 
[3] [http://www.developer.com/net/csharp/article.php/3722931/Dependency-Injection-with-SpringNet.htm Dependency Injection with Spring .NET] 
[4] [http://needle.rubyforge.org/api/ Dependency Injection in Ruby]
[5] [http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc ]

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T15:14:14Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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.[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 =
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.

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.

= 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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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[http://static.springsource.org/spring/docs/2.5.x/reference/aop.html], 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. [[image:di_image2.png]] 

'''''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 [http://en.wikipedia.org/wiki/Circular_dependency].
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection Setter injection] it won’t allow changes to the dependency, once it is created.

= Conclusion =

= References and Notes =
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling] 
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection] 
[3] [http://www.springsource.org/ Spring Framework] 
[4] [http://www.opensymphony.com/xwork/ Xwork] 
[5] [http://excalibur.apache.org/framework/index.html Excalibur Apache Avalon] 
[6] [http://www.picocontainer.org/ PicoContainer] 
[7] [http://hivelogic.com/ Hivelogic] 
[8] [http://static.springsource.org/spring/docs/2.5.x/reference/aop.html Aspect Oriented Programming] 
[9] [http://en.wikipedia.org/wiki/Circular_dependency Circular Dependency] 

= Further Reading =

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T15:09:02Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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.[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 =
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.

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.

= 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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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[ ], 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. [[image:di_image2.png]] 

'''''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 http://en.wikipedia.org/wiki/Circular_dependency.
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection Setter injection] it won’t allow changes to the dependency, once it is created.

= Conclusion =

= References and Notes =
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling] 
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection] 
[3] [http://www.springsource.org/ Spring Framework] 
[4] [http://www.opensymphony.com/xwork/ Xwork] 
[5] [http://excalibur.apache.org/framework/index.html Excalibur Apache Avalon] 
[6] [http://www.picocontainer.org/ PicoContainer] 
[7] [http://hivelogic.com/ Hivelogic] 

= Further Reading =

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T15:07:01Z

Whiteopal: /* References and Notes */

'''Dependency Injection'''

__TOC__

= 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.[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 =
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.

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.

= 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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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[ ], 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. [[image:di_image2.png]] 

'''''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 http://en.wikipedia.org/wiki/Circular_dependency.
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection Setter injection] it won’t allow changes to the dependency, once it is created.

= Conclusion =
= References and Notes =
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling] 
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection] 
[3] [http://www.springsource.org/ Spring Framework] 
[4] [http://www.opensymphony.com/xwork/ Xwork] 
[5] [http://excalibur.apache.org/framework/index.html Excalibur Apache Avalon] 
[6] [http://www.picocontainer.org/ PicoContainer] 
[7] [http://hivelogic.com/ Hivelogic] 

= Further Reading =

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T15:06:15Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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.[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 =
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.

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.

= 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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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[ ], 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. [[image:di_image2.png]] 

'''''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 http://en.wikipedia.org/wiki/Circular_dependency.
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection Setter injection] it won’t allow changes to the dependency, once it is created.

= Conclusion =
= References and Notes =
[1] [http://www.codeproject.com/KB/architecture/DependencyInjection.aspx Dependency Injection for Loose Coupling]
[2] [http://www.springframework.net/doc-latest/reference/html/objects.html#objects-factory-collaborators Dependency injection]
[3] [http://www.springsource.org/ Spring Framework]
[4] [http://www.opensymphony.com/xwork/ Xwork]
[5] [http://excalibur.apache.org/framework/index.html Excalibur Apache Avalon]
[6] [http://www.picocontainer.org/ PicoContainer]
[7] [http://hivelogic.com/ Hivelogic]

= Further Reading =

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T14:45:04Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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.[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 =
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.

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.

= 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.[http://www.springsource.org/]
* '''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.[http://www.opensymphony.com/xwork/]
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.[http://excalibur.apache.org/framework/index.html]
* '''PicoContainer''' - It is a highly focused DI framework available.[http://www.picocontainer.org/]
* '''Hivelogic''' – Another DI framework to inject dependencies.[http://hivelogic.com/]

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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. [/////////////////////] Before using Spring, let us study some basic features of Spring. We will cover only a brief overview of the Spring Framework. For better understanding of Spring, please visit the site: [ ////////////////////////////]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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. [[image:di_image2.png]] 

'''''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 http://en.wikipedia.org/wiki/Circular_dependency.
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection Setter injection] it won’t allow changes to the dependency, once it is created.

= Conclusion =
= References and Notes =
= Further Reading =

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T05:21:08Z

Whiteopal: /* Type 3- Constructor Injection */

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''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.
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is a highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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: ////////////////////////////////////////provide external link

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. [/////////////////////] Before using Spring, let us study some basic features of Spring. We will cover only a brief overview of the Spring Framework. For better understanding of Spring, please visit the site: [ ////////////////////////////]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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. [[image:di_image2.png]] 

'''''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 http://en.wikipedia.org/wiki/Circular_dependency.
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection Setter injection] it won’t allow changes to the dependency, once it is created.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T01:53:47Z

Whiteopal: /* Type 3- Constructor Injection */

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''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.
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is a highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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: ////////////////////////////////////////provide external link

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. [/////////////////////] Before using Spring, let us study some basic features of Spring. We will cover only a brief overview of the Spring Framework. For better understanding of Spring, please visit the site: [ ////////////////////////////]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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. [[image:di_image2.png]] 

'''''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 http://en.wikipedia.org/wiki/Circular_dependency.
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection Setter injection] it won’t allow changes to the dependency, once it is created.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T01:45:38Z

Whiteopal: /* Type 3- Constructor Injection */

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''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.
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is a highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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: ////////////////////////////////////////provide external link

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. [/////////////////////] Before using Spring, let us study some basic features of Spring. We will cover only a brief overview of the Spring Framework. For better understanding of Spring, please visit the site: [ ////////////////////////////]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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. [[image:di_image2.png]] 

'''''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 http://en.wikipedia.org/wiki/Circular_dependency.
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, [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection Setter injection] it won’t allow changes to the dependency, once it is created.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T01:07:52Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''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.
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is a highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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: 
[[Image:Di_image1.png]]

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: ////////////////////////////////////////provide external link

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. [/////////////////////] Before using Spring, let us study some basic features of Spring. We will cover only a brief overview of the Spring Framework. For better understanding of Spring, please visit the site: [ ////////////////////////////]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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. [[image:di_image2.png]] 

'''''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 http://en.wikipedia.org/wiki/Circular_dependency.
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, <br. [[image:di_image3.png]] 

'''''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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Type_2-_Setter_Injection Setter injection] it won’t allow changes to the dependency, once it is created.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:43:17Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''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.
* '''Apache Avalon'''- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is a highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== 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 [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch5_5e_dr#Types_of_Dependency_Injection section 4].

'''''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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

'''''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

'''''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

'''''App.Config'''''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a class on which DoctorService depends. [[image:di_image2.png]] 

'''''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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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 that scenario very well because it guarantees that the Dependency is always present. If the depending class absolutely cannot function without the Dependency, that guarantee is valuable. Constructor-injection enforces the order of initialization and prevents circular dependencies http://en.wikipedia.org/wiki/Circular_dependency.
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, <br. [[image:di_image3.png]] 

'''''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 parameterized constructor which Spring framework will use to instantiate the value of prescriptionDAO.
Now, question is that 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 same.
The advantage of using Constructor Injection is that it can create the objects at the time of instantiation itself and hence guarantee the developer that objects will definitely get created and no exception will be raised , but it won’t allow to change the dependency once created. This we can achieve by using Setter injection, calling setter method at any future point of time.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:38:12Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

'''''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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

'''''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

'''''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

'''''App.Config'''''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a class on which DoctorService depends. [[image:di_image2.png]] 

'''''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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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 that scenario very well because it guarantees that the Dependency is always present. If the depending class absolutely cannot function without the Dependency, that guarantee is valuable. Constructor-injection enforces the order of initialization and prevents circular dependencies http://en.wikipedia.org/wiki/Circular_dependency.
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, <br. [[image:di_image3.png]] 

'''''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 parameterized constructor which Spring framework will use to instantiate the value of prescriptionDAO.
Now, question is that 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 same.
The advantage of using Constructor Injection is that it can create the objects at the time of instantiation itself and hence guarantee the developer that objects will definitely get created and no exception will be raised , but it won’t allow to change the dependency once created. This we can achieve by using Setter injection, calling setter method at any future point of time.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:36:29Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

''''' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

'''''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a class on which DoctorService depends. [[image:di_image2.png]] 

'''''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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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 that scenario very well because it guarantees that the Dependency is always present. If the depending class absolutely cannot function without the Dependency, that guarantee is valuable. Constructor-injection enforces the order of initialization and prevents circular dependencies http://en.wikipedia.org/wiki/Circular_dependency.
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, <br. [[image:di_image3.png]] 

'''''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 parameterized constructor which Spring framework will use to instantiate the value of prescriptionDAO.
Now, question is that 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 same.
The advantage of using Constructor Injection is that it can create the objects at the time of instantiation itself and hence guarantee the developer that objects will definitely get created and no exception will be raised , but it won’t allow to change the dependency once created. This we can achieve by using Setter injection, calling setter method at any future point of time.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:35:15Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

''''' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

'''''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a class on which DoctorService depends. [[image:di_image2.png]] 

'''''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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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 that scenario very well because it guarantees that the Dependency is always present. If the depending class absolutely cannot function without the Dependency, that guarantee is valuable. Constructor-injection enforces the order of initialization and prevents circular dependencies http://en.wikipedia.org/wiki/Circular_dependency.
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, <br. [[image:di_image3.png]] 

'''''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 parameterized constructor which Spring framework will use to instantiate the value of prescriptionDAO.
Now, question is that 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:
<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>

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:32:31Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

''''' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

'''''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a class on which DoctorService depends. [[image:di_image2.png]] 

'''''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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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 that scenario very well because it guarantees that the Dependency is always present. If the depending class absolutely cannot function without the Dependency, that guarantee is valuable. Constructor-injection enforces the order of initialization and prevents circular dependencies http://en.wikipedia.org/wiki/Circular_dependency.
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, <br. [[image:di_image3.png]] 

'''''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);
}
}

File:Di image3.png

2010-11-03T00:29:15Z

Whiteopal: Dependency Injection image1

Dependency Injection image1

File:Di image2.png

2010-11-03T00:26:33Z

Whiteopal: Dependency Injection image1

Dependency Injection image1

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:25:57Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

'' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a class on which DoctorService depends. [[image:di_image2.png]]

'''''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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:22:42Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

'' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a 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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:20:33Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

'' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a 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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:18:00Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

'' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a 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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:14:59Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

'' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a 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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:12:51Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

'' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a 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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

'''''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 defined 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 path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory(or Container) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:06:19Z

Whiteopal:

'''Dependency Injection'''

__TOC__

= 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. 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 =
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.

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.

= 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.
* '''XWork''' - It is a standalone framework and mostly works in conjunction with Webworks. It is highly effective command pattern framework that provides a lot of features for DI.
* Apache Avalon- This is also a container framework which supports the dependency injection design pattern. This frameworks is now divided into sub-frameworks.
* '''PicoContainer''' - It is highly focused DI framework available.
* '''Hivelogic''' – Another DI framework to inject dependencies.

== Example of Dependency Injection Framework ==

Let us take a simple example to understand the basic idea of DI.
Suppose we have an Employee class which depends on the Department object, and we need some Assembler (DI Framework) to instantiate the Department field of Employee class, rather than Employee creates this object for itself. It will delegate this process of instantiation to any of the framework selected to do this job by using any form of configuration files, which are mostly .xml files. We will see comprehensive example using the framework in the next section.

'' 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;
}
}
Now, it is the framework (any one of the selected frameworks mentioned above) which will instantiate the Department object by looking into the configuration file for any existing dependencies of Employee object, and thus forms Employee object with Department instance. For example, in Spring Framework, the configuration file will be ApplicationContext.xml, where this binding of beans is done as:

''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: 
[[Image:Di_image1.png]]

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, we only need to update our 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 the 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 the technique to add the dependency for interfaces in the components at run time, and components implement these interfaces based on the injected dependency. Spring framework does not support interface injection, so let us see this injection by using 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, and we have ApplicationServiceImpl class(component) implementing the ApplicationService inteface, which will do the specific implementation of the ApplicationDAO interface provided by the container as per the configuration.

''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 use configuration file for lookup,

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;
}
}

Configuration File that will be used by MyClass file to lookup the dependency configurations.

''App.Config''

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key=" selectedClass " value="myPackage. AccountApplicationDAO " />
</appSettings>
</configuration>

Here, in this example, validateEntity() in ApplicationServiceImpl will call getEntity() using
ApplicationDAO reference, and which getEntity() is invoked (of Accoun ot Customer ) actually depends on the dependency that is injected via 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 take an example of Setter injection by using Spring Framework. [] Before using Spring, let us study some basic features of Springs. We are not including detailed explanation and complicacies of Springs here, for better understanding you can visit the site: [ ]

* Spring is a lightweight container which along with supporting features like Dependency Injection, also include other ones as: Container, Framework, AOP[ ], 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

We will see Setter and Constructor Injection using 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 a class on which DoctorService depends.

''DoctorService.java'''''Bold text'''

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;
}
}

In the above example, the invoking object is responsible for setting the PrescriptionDAO dependency. Now there is no code inside the class that is creating new instance of PrescriptionDAO, because this will be done by the Spring container by looking for dependencies of DoctorService inside applicationContext.xml file, which is usually stired in WEB-INF folder of web application

Spring framework uses setter method to create this dependent object, and note the <property> tag which is used inside ApplicationContext.xml file for setter injection.
For Constructor injection, it uses another tag, <constructor-arg>, we will refer to it later.

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 defined 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 for DoctorService class.
DoctorService doctorService= (DoctorService) factory.getBean(“doctorServiceId”);

}
}
Here, first path for the ApplicationContext is given and this file is used a s resource by the container. BeanFactory (or Conatiner) uses this xml file to get the bean we defined inside the configuration file.

However Setter Injection adds the abstraction for the developer to know which dependencies are needed when. But 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.

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:02:10Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-03T00:00:36Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:57:37Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:45:25Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:44:51Z

Whiteopal:

File:Di image1.png

2010-11-02T23:44:13Z

Whiteopal: Dependency Injection image1

Dependency Injection image1

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:35:47Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:35:13Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:34:40Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:32:48Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:32:07Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:31:48Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:29:41Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:27:27Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:20:43Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:13:00Z

Whiteopal:

CSC/ECE 517 Fall 2010/ch5 5e dr

2010-11-02T23:11:34Z

Whiteopal:

'''Dependency Injection'''

CSC/ECE 517 Fall 2010/ch2 S24 rm

2010-10-01T00:12:07Z

Whiteopal: /* C++ Template Metaprogramming */

'''Metaprogramming in Statically Typed Languages'''

''"I'd rather write programs that write programs than write programs" - Richard Sites''

__TOC__

= Introduction =

Metaprogramming is an inherent feature of dynamically typed languages [e.g. Ruby]. However, achieving metaprogramming in statically typed languages [e.g. Java] becomes complex due to compile time abstraction verification. In this topic, we explore how tools and packages are usedto implement metaprogramming in statically typed languages .

== Metaprogramming ==

Metaprogramming is a programming technique of writing computer programs that write or manipulate other programs or themselves, as data. [http://en.wikipedia.org/wiki/Metaprogramming] In other words, it is a programming technique of writing programs with a higher level of abstraction to make it appear as generative programming.

Metaprogramming involves two kinds of languages-
* '''Meta-language''' is the language in which meta-programs, which construct or manipulate other programs, are written.
* '''Object-language''' is the language of programs being manipulated.
This makes them ‘meta level programs’ whose problem domain are other ‘base level programs’.

[[Image:Meta_1.jpg]]

The ability of a programming language to be its own metalanguage is called reflection or reflexivity.

Simple example of a metaprogram:
 Let us consider a totally fabricated example for our understanding at very high level. Suppose we need to write a C program that printed the following 500 lines of text with a restriction that the program could not use any kind of loop or goto instruction.

Output expected:

1 Mississippi
2 Mississippi
3 Mississippi
4 Mississippi
...
499 Mississippi
500 Mississippi

In C this would be then coded as:

#include <stdio.h>
int main(void) {
printf("1 Mississippi\n");
printf("2 Mississippi\n");
-
-
-
printf("499 Mississippi\n");
printf("500 Mississippi\n");
return 0;
}

With the power of a metaprogramming language we can write another program that writes this program automatically.

Ruby code:

File.open('mississippi.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(500) do |i|
output.puts " printf(\"#{i} " +
"Mississippi\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called mississippi.c with the expected 500+ lines of C source code.Here, mississippi.c is the generated code and ruby code is the metaprogram.

== Applications of Metaprogramming ==

Metaprogramming is an attractive technique needed when one needs to alter the behavior of a program at run time. Due to its generative nature, it has numerous applications in program development. It can achieve program development without rewriting boiler-plate code [http://en.wikipedia.org/wiki/Boilerplate_text] all the time, ensuring efficiency, increasing modularity and minimizing inconsistent implementation errors. Program generators and program analyzers are the two main categories of meta programs. Metaprograms can be compilers, interpreters, type checkers etc. Some commonly used applications include using a program that outputs source code to -
* generate sine/cosine/whatever lookup tables
* to extract a source-form representation of a binary file
* to compile your bitmaps into fast display routines
* to extract documentation, initialization/finalization code, description tables, as well as normal code from the same source files
* to have customized assembly code, generated from a perl/shell/scheme script that does arbitrary processing
* to propagate data defined at one point only into several cross-referencing tables and code chunks.

Programmers can focus more on the main business logic and new features to be implemented rather than writing repetitive chunks of code (e.g. setups, stubs)[1].

= Typing in Programming Languages =

Earlier programming languages [e.g. Assembly] were written such that each machine level function was reflected in the program code. With advancement in programming languages a certain level of abstraction was reached wherein lower level details were abstracted with one functional unit of work and represented by fewer lines of code e.g. primitive variables are represented with higher level abstract classes. With this abstraction arose a need for checking the validity of operations that could be performed with these abstractions in place.

Typing in programming languages is property of operations and variables in the language that ensure that certain kinds of values that are invalid are not used in operations with each other. Errors related to these are known as type errors. Type checking is the process of verifying and enforcing the constraints of types. Compile time type checking also known as static type checking. Run time type checking is known as dynamic type checking. If a language specification requires its typing rules strongly (i.e., more or less allowing only those automatic type conversions which do not lose information), one can refer to the process as strongly typed, if not, as weakly typed.[http://en.wikipedia.org/wiki/Type_system]
The above classification can be represented as -

[[Image:Meta_2.jpg]]

== Statically Typed Programming Languages ==

Statically typed languages ensure that a fixed type is assigned by the programmer to every variable and parameter. Thus, every expression type can be deduced and type checked during compilation. Static languages try to fix most errors during compile time and strive to minimize failures during run time. Due to this there are many type constraints on the programmer while coding. At run time, the program uses the classes that it has been given and in this way statically typed languages make distinctions between what happens at compile time and what happens at run time. Examples of statically typed languages are C, C++, Java, C#.

== Dynamically Typed Programming Languages ==

In dynamically typed languages, the variables and parameters do not have a designated type and may take different values at different times. In all the operations, the operands must be type checked at runtime just before performing the operation. Dynamically typed languages don’t need to make a distinction between classes created at compile time and classes provided. It is possible to define classes at run time and in fact, classes are always defined at run time. These eliminate many developer constraints by avoiding the need of book keeping, declarations etc. Due to this flexibility these languages make an ideal candidate for prototyping and are widely used in agile development environments. However, dynamic languages are known to have performance issues. Static languages have code optimization features at compile time, but dynamic languages allow runtime code optimizations only. [http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages] In dynamically typed languages, the interpreter deduces type and type conversions, this makes development time faster, but it also can provoke runtime failures. These runtime failures are caught early on during compile time for statically typed languages.
Examples of dynamically typed languages include Perl, Python, JavaScript, PHP, Ruby, Groovy.

= Metaprogramming in statically typed languages =

In safety languages [syntactically verbose], metaprogramming is not a standard feature, it can however be achieved. Also, static typing in meta-programs has a number of advantages. In addition to guaranteeing that the meta-program encounters no type-errors while manipulating object-programs, a statically typed metaprogramming language can also guarantee that any of the object-programs generated by the meta-program are also type-correct. A disadvantage of these type system is that (in case of meta-programming languages with weaker type systems) they sometime may be too restrictive in object-programs that the programmer is allowed to construct.

== Techniques and Packages ==

Many language features can be leveraged to achieve some form of characteristics needed to achieve metaprogramming. For instance, languages that support reflection also allow for dynamic code generation. e.g. In Microsoft .NET Framework use of "System.Reflection.Emit" namespace is used to generate types and methods at runtime.

=== Reflection ===

Reflection is a valuable language feature to facilitate metaprogramming. Reflection is defined as the ability of a programming language to be its own meta-language. Thus, reflection is writing programs that manipulate other programs or themselves. [http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm] 
e.g. In Java, reflection enables to discover information about the loaded classes:
* Fields,
* Methods and constructors
* Generics information
* Metadata annotations
It also enables to use these metaobjects to their instances in run time environment.
E.g. Method.invoke(Object o, Object… args)
With the Java reflection API, you can interrogate an object to get all sorts of information about its class.

Consider the following simple example:
public class HelloWorld {
public void printName() {
System.out.println(this.getClass().getName());
}
}

The line
(new HelloWorld()).printName();
sends the string HelloWorld to standard out. Now let x be an instance of HelloWorld or one of its subclasses. The line
x.printName();
sends the string naming the class to standard out.

The printName method examines the object for its class (this.getClass()). In doing so, the decision of what to print is made by delegating to the object's class. The method acts on this decision by printing the returned name. Without being overridden, the printName method behaves differently for each subclass than it does for HelloWorld. The printName method is flexible; it adapts to the class that inherits it, causing the change in behavior.

=== Annotations ===

Annotations are a metaprogramming facility that allow the code to be marked with defined tags. Many APIs require a fair amount of boilerplate code. This boilerplate could be generated automatically by a tool if the program were “decorated” with annotations indicating which methods were remotely accessible. Metadata provided using annotations is beneficial for documentation, compiler checking, and code analysis. One can use this metadata to indicate if methods are dependent on other methods, if they are incomplete, if a certain class must reference another class, and so on. It is used by the compiler to perform some basic compile-time checking. For example there is a override annotation that lets you specify that a method overrides another method from a superclass. At this, the Java compiler will ensure that the behavior you indicate in your metadata actually happens at a code level as well.

An “annotation” has an “annotation type” associated with it which is used for defining it. It is used when you want to create a custom annotation. The type is the actual construct used, and the annotation is the specific usage of that type. An annotation type definition takes an "at" (@) sign, followed by the interface keyword plus the annotation name. On the other hand, an annotation takes the form of an "at" sign (@), followed by the annotation type [http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm].

Example to Define an Annotation (Annotation type)

public @interface MyAnnotation {
String doSomething();}
Example to Annotate Your Code (Annotation)
MyAnnotation (doSomething="What to do")
public void mymethod() {
....
}

==== Annotation Types ====
There are three annotation types:
* '''Marker:''' Marker type annotations have no elements, except the annotation name itself.
Example:
public @interface MyAnnotation {
}
Usage:
@MyAnnotation
public void mymethod() {
....
}

* '''Single-Element:''' Single-element, or single-value type, annotations provide a single piece of data only. This can be represented with a data=value pair or, simply with the value (a shortcut syntax) only, within parenthesis.
Example:

public @interface MyAnnotation
{
String doSomething();
}

Usage:
@MyAnnotation ("What to do")
public void mymethod() {
....
}

* '''Full-value or multi-value:''' Full-value type annotations have multiple data members. Therefore, you must use a full data=value parameter syntax for each member.
Example:
public @interface MyAnnotation {
String doSomething();
int count; String date();
}
Usage:
@MyAnnotation (doSomething="What to do", count=1,
date="09-09-2005")
public void mymethod() {

=== Generics ===

Generic programming is a style of computer programming in which algorithms are written in terms of to-be-specified-later types that are then instantiated when needed for specific types provided as parameters. [http://en.wikipedia.org/wiki/Generic_programming] Java Generics are primarily a way for library authors to write something once, which users can customize to their own types. They allow the creation of classes and methods that work in the same way on different types of objects. The term "generic" comes from the idea that we'd like to be able to write general algorithms that can be broadly reused for many types of objects rather than having to adapt our code to fit each circumstance.

Generics add a way to specify concrete types to general purpose classes and methods that operated on object before. A Java collection is a flexible data structure that can hold heterogeneous objects where the elements may have any reference type. When you take an element out of a collection, you must cast it to the type of element that is stored in the collection. Generics provides a way for you to communicate the type of a collection to the compiler, so that it can be checked. Once the compiler knows the element type of the collection, the compiler can check that the collection has been used consistently and can insert the correct casts on values being taken out of the collection.[5] Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parametrized types (which are technically known as raw types).

Consider a non-generic example:
//This program removes 4-letter words from c. Elements must be strings
static void expurgate(Collection c)
{
for (Iterator i = c.iterator(); i.hasNext(); )
if (((String) i.next()).length() == 4)
i.remove();
}
Here is the same example modified to use generics:
//This program removes the 4-letter words from c
static void expurgate(Collection<String> c)
{
for (Iterator<String> i = c.iterator(); i.hasNext(); )
if (i.next().length() == 4)
i.remove();
}
The declaration above reads as “Collection of String c.” Collection is a generic class that takes ‘String’ as its type parameter. The code using generics is clearer and safer. Unsafe cast and a number of extra parentheses have been eliminated. More importantly, we have moved part of the specification of the method from a comment to its signature, so the compiler can verify at compile time that the type constraints are not violated at run time.[http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf]

=== Template Metaprogramming ===
Template metaprogramming(TMP) or Static Metaprogramming is a technique that allows the execution of programs at compile-time. It uses extremely early binding.
A primary requirement for a metaprogramming language is providing high-level abstractions to hide the internal representation of base programs.[http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf] Each template language is specific for a base language and is generated from it. In this sense, a language of templates is a superset of the base language. Thus templates are abstractions that encapsulate a program pattern written by example. This concept has been explained in detail in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#C.2B.2B_Template_Metaprogramming section 3.2.5]

Uses of template metaprogramming:
* Compile-time dimensional analysis
* Multiple dispatch
* Design patterns
* Code optimization
* Lexing and parsing

== Packages ==

=== Javassist (Java Programming Assistant) ===

Javassist is a Java library providing means to manipulate the Java bytecode of an application. It provides the support for structural reflection, i.e. the ability to change the implementation of a class at runtime. [http://www.csg.is.titech.ac.jp/~chiba/javassist/] Javassist is explicit metaprogramming, in which the metalanguage is Java. It is a load-time reflective system for Java which enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it. Unlike other similar bytecode editors, Javassist provides two levels of API: source level and bytecode level.

If the users use the source-level API, they can edit a class file without knowledge of the specifications of the Java bytecode. They do not have to even write an inserted bytecode sequence; Javassist instead can compile a fragment of source text on line (for example, just a single statement). This ease of use is a unique feature of Javassit against other tools. One can even specify inserted bytecode in the form of source text and Javassist compiles it on the fly. On the other hand, the bytecode-level API allows the users to directly edit a class file as other editors. Thus it makes Java bytecode manipulation simple.

Javassist has the following applications:
* Aspect Oriented Programming: Javassist can be a good tool for introducing new methods into a class and for inserting before/after/around advice at the both caller and callee sides.
* Reflection: One of applications of Javassist is runtime reflection; Javassist enables Java programs to use a metaobject that controls method calls on base-level objects. No specialized compiler or virtual machine are needed.
* Remote method invocation: Another application is remote method invocation. Javassist enables applets to call a method on a remote object running on the web server. Unlike the Java RMI, the programmer does notneed a stub compiler such as rmic; the stub code is dynamically produced by Javassist.

Example:
BufferedInputStream fin = new BufferedInputStream(new FileInputStream("Point.class"));
ClassFile cf = new ClassFile(new DataInputStream(fin));

A ClassFile object can be written back to a class file. write() in ClassFile writes the contents of the class file to a given DataOutputStream. ClassFile provides addField() and addMethod() for adding a field or a method (note that a constructor is regarded as a method at the bytecode level). It also provides addAttribute() for adding an attribute to the class file.

To examine every bytecode instruction in a method body, CodeIterator is useful. A CodeIterator object allows you to visit every bytecode instruction one by one from the beginning to the end. To otbain this object, do as follows:

ClassFile cf = ... ;
MethodInfo minfo = cf.getMethod("move"); // we assume move is not overloaded.
CodeAttribute ca = minfo.getCodeAttribute();
CodeIterator i = ca.iterator();

Other extensions are being developed to include reflective systems for C++ and Java e.g. OpenC++ and OpenJava which are extensible preprocessors based on compile-time reflection in C++ and Java respectively.

=== JRuby ===

JRuby is a complete implementation of Ruby in Java. The scripting and functional features of the Ruby language can be used by Java developers.[http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules] Simple metaprogramming techniques can be extended from Ruby so that Java packages are mapped onto to Ruby modules. This would be something like a Ruby-Java Bridge, since JRuby can be run from any platform with a JVM.

Example:
Using JRuby API calling JRuby from Java

import org.jruby.*;
public class SimpleJRubyCall {
public static void main(String[] args) {
Ruby runtime = Ruby.getDefaultInstance();
runtime.evalScript(“puts 1+2”);
}
}

With metaprogramming using JRuby one can
* add methods to class,
* add instance methods
* add to have Java classes

Since metaprogramming empowers the programmer to create domain specific languages(DSL), the ones created by JRuby can always leverage Java libraries to build wrapper functionalities.
e.g. Simple JRuby DSL on top of HtmlUnit

=== AspectJ ===
Another library worth mentioning here is AspectJ. It enforces the aspect oriented programming (AOP) approach in Java. Aspect oriented programming is a complimentary programming paradigm to object oriented programming and is used to improve the modularity of software systems. Thus, while object oriented programming is great for modeling common behavior on a hierarchy of objects, aspect oriented programming allows you to define cross-cutting concerns by adding direct semantics and can be applied across heterogeneous object models. [http://static.springsource.org/spring/docs/2.0.x/reference/aop.html] Applications of aspect oriented programming include logging, instrumenting and debugging.

In object oriented programs, the natural unit of modularity is the class. In AspectJ, aspects modularize concerns that affect more than one class. In addition to classes, aspect oriented programming uses 'aspects'. Aspects enable modularization of crosscutting concerns such as transaction management that cut across multiple types and objects. Thus, AspectJ package achieves metaprogramming features with more controllability.

AspectJ introduces declaring aspects in the statically typed language Java by using 3 key concepts -
* Join Points - well defined points in program execution
* Advice - defines additional code to be executed around join points
* Pointcut - define those points in the source code of a program where an advice will be applied

The core task of AspectJ's advice weaver is to statically transform a program so that at runtime it will behave according to the AspectJ language semantics. The AspectJ weaver takes class files as input and produces class files as output. The weaving process itself can take place at one of three different times: compile-time, post-compile time, and load-time. These two java files are 'woven' together by compiler i.e. the class and the aspect behavior are tied together. This is also known as 'plugging-in' the aspect. [http://oreilly.com/catalog/9780596006549]

Example - Simple tracing/logging

Consider the HelloWorld class below which implements an application that simply displays "Hello World!" on the standard output.
package helloworld;
class HelloWorld {
public static void main(String[] args) {
new HelloWorld().printMessage();
}
void printMessage() {
System.out.println("Hello world!");
}
}

Consider another Java source file with an aspect definition as follows -
package helloworld;
aspect Trace of eachobject(instanceof(HelloWorld)) {
pointcut printouts(): receptions(void printMessage());
before(): printouts() {
System.out.println("*** Entering printMessage ***");
}
after(): printouts() {
System.out.println("*** Exiting printMessage ***");
}
}

In above example, the Trace aspect injects tracing messages before and after method main of class HelloWorld. If one does not want tracing, one can simply leave the aspect out and plug it in as and when required.

In contrast to reflection[low level], AspectJ provides more carefully controlled power, drawing on the rules learned from object-oriented development to encourage a clean and understandable program structure. An aspect imposes behavior on a class, rather than a class requesting behavior from an aspect. An aspect can modify a class without needing to edit that class - also known as 'reverse inheritance'.

=== MetaJ ===

MetaJ is another package that supports metaprogramming in the Java language. A MetaJ program consists of the Java code with special metaprogramming declarations that will control how the output code is created. It uses templates and reflection. Templates are abstractions that encapsulate a program pattern written by example. Templates are translated to Java classes, so they can be accessed in the metaprogram. Accessing patterns by example inside ordinary Java programs is a major feature of MetaJ programming. [http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment]

Language Dependency:
MetaJ comprises of a set of concepts that are independent of the base language. These are syntax trees, code references, code iterators and code templates. A framework is defined which in which features common to most languages are abstracted. This supports independence from base language. Thus, generic operations can be defined and components that are language dependent can be plugged onto it.

Execution Flow Representation:

[[Image:Meta_3.jpg]]

Example:

Template : SampleTempl

package myTempl;
language = Java // base language plugin
template #CompilationUnit SampleTempl{
#[#PackageDeclaration:pck]#
#[#ImportDeclarationList:imps]#
class SampleTempl { ... }
#TypeDeclaration:td
}

Instance of Template : Java Code

package myTempl;
import metaj.framework.AbstractTemplate;
public class SampleTempl extends AbstractTemplate{
public final Reference imps, td, pck;
... // Implementation of superclass abstract methods
}

Java SDK7 has added support for dynamic typing and metaprogramming and includes MetaJ implementation.

=== C++ Template Metaprogramming ===

In C++, [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#Template_Metaprogramming static metaprogramming] is implemented with the help of reflection. The most important implementation of reflection in C++ is using the feature of run time type-identification (RTTI) [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules]. RTTI is a system that keeps information about an object's data type in memory at run time. Run-time type information can apply to simple data types, such as integers and characters, or to generic objects. Enabling RTTI in C++ allows the use of dynamic_cast<> operation, the typeid operator or exceptions [http://en.wikipedia.org/wiki/Run-time_type_information].

The template mechanism in C++ allows defining parametrized classes and functions. Templates together with other C++ features constitute a Turing-complete, compile-time sub- language of C++. A Turing-complete language is a language with at least a conditional and a looping construct. C++ can be considered to be a two-level language since a C++ program may contain both static code, which is evaluated at compile time, and dynamic code, which is executed at run time. Template meta-programs are the part of a C++ source that is executed during compilation. A meta-program can access information about types not generally available to ordinary programs [9].

Given below is an example of how to use templates for writing a common recursive factorial program:
template<int count>
class FACTOR{
public:
enum {RESULT = count * FACTOR<count-1>::RESULT};
};
class FACTOR<1>{
public:
enum {RESULT = 1};
};

If we write this-
int j = FACTOR<5>::RESULT;

The above line will calculate the value of 5 factorial. As we instantiate FACTOR<5> the definition of this class depends on FACTOR<4>, which in turn depend on FACTOR<3> and so on. The compiler needs to create all these classes until the template specialization FACTOR<1> is reached. This means the entire recursion is done by the compiler during compile time and it uses the result as if it is a constant.

= Conclusion =

Dynamically typed languages are best suited to provide support for metaprogramming due to their inherent nature of easily overcoming distinction between code and data e.g. Lisp provides this feature of interchangeability. Code and data are both represented in Lisp as lists, so any list can easily be treated as either code or data.
It’s simple, therefore, to manipulate code as data, and then execute it – either via EVAL or by returning it as the result of a macro expansion. [3]

Thus, statically typed languages achieve metaprogramming using various techniques and tools to achieve the level of flexibility that dynamic languages provide immanently.

= References and Notes =

*[1] [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming]
*[2] [http://en.wikipedia.org/wiki/Boilerplate_text Boilerplate Text]
*[3] [http://en.wikipedia.org/wiki/Type_system Type System]
*[4] [http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages Bandeali, M. 2009. ''Dynamically and Statically typed languages'']
*[5] [http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm Java Reflection in Action]
*[6] [http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm An Introduction to Java Annotations]
*[7] [http://en.wikipedia.org/wiki/Generic_programming Generic Programming]
*[8] [http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf Haapakorpi, M. ''Metaprogramming in Java'']
*[9] [http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf Attardi, G., Cisternino, A. ''Reflection support by means of template metaprogramming'']
*[10] [http://www.csg.is.titech.ac.jp/~chiba/javassist/ Javassist]
*[11] [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules Metaprogramming with Ruby: Mapping Java Packages Onto Ruby Modules]
*[12] [http://static.springsource.org/spring/docs/2.0.x/reference/aop.html Aspect Oriented Programming with Spring]
*[13] [http://oreilly.com/catalog/9780596006549 Miles, R. 2004 ''AspectJ Cookbook'' O'Reilly Media]
*[14] [http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment Oliveira, A.A., Braga, T.H, Maia, M.A., Bigonha and R.S. 2004. MetaJ: An Extensible Environment for Metaprogramming in Java, ''Journal of Universal Computer Science, vol. 10, no. 7 (2004), 872-891'']
*[15] [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules Metaprogramming with Ruby: Mapping Java Packages Onto Ruby Modules ]
*[16] [http://en.wikipedia.org/wiki/Run-time_type_information Run-time Type Information]

= Further Reading =

*[http://www.cs.tut.fi/~kk/webstuff/MetaprogrammingCpp.pdf Metaprogramming in C++]
*[http://en.wikipedia.org/wiki/Automatic_programming Automatic/Generative Programming]
*[http://www.slideshare.net/dogangoko/new-features-of-java7-se-presentation News in the upcoming Java 7]

CSC/ECE 517 Fall 2010/ch2 S24 rm

2010-10-01T00:10:57Z

Whiteopal: /* References and Notes */

'''Metaprogramming in Statically Typed Languages'''

''"I'd rather write programs that write programs than write programs" - Richard Sites''

__TOC__

= Introduction =

Metaprogramming is an inherent feature of dynamically typed languages [e.g. Ruby]. However, achieving metaprogramming in statically typed languages [e.g. Java] becomes complex due to compile time abstraction verification. In this topic, we explore how tools and packages are usedto implement metaprogramming in statically typed languages .

== Metaprogramming ==

Metaprogramming is a programming technique of writing computer programs that write or manipulate other programs or themselves, as data. [http://en.wikipedia.org/wiki/Metaprogramming] In other words, it is a programming technique of writing programs with a higher level of abstraction to make it appear as generative programming.

Metaprogramming involves two kinds of languages-
* '''Meta-language''' is the language in which meta-programs, which construct or manipulate other programs, are written.
* '''Object-language''' is the language of programs being manipulated.
This makes them ‘meta level programs’ whose problem domain are other ‘base level programs’.

[[Image:Meta_1.jpg]]

The ability of a programming language to be its own metalanguage is called reflection or reflexivity.

Simple example of a metaprogram:
 Let us consider a totally fabricated example for our understanding at very high level. Suppose we need to write a C program that printed the following 500 lines of text with a restriction that the program could not use any kind of loop or goto instruction.

Output expected:

1 Mississippi
2 Mississippi
3 Mississippi
4 Mississippi
...
499 Mississippi
500 Mississippi

In C this would be then coded as:

#include <stdio.h>
int main(void) {
printf("1 Mississippi\n");
printf("2 Mississippi\n");
-
-
-
printf("499 Mississippi\n");
printf("500 Mississippi\n");
return 0;
}

With the power of a metaprogramming language we can write another program that writes this program automatically.

Ruby code:

File.open('mississippi.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(500) do |i|
output.puts " printf(\"#{i} " +
"Mississippi\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called mississippi.c with the expected 500+ lines of C source code.Here, mississippi.c is the generated code and ruby code is the metaprogram.

== Applications of Metaprogramming ==

Metaprogramming is an attractive technique needed when one needs to alter the behavior of a program at run time. Due to its generative nature, it has numerous applications in program development. It can achieve program development without rewriting boiler-plate code [http://en.wikipedia.org/wiki/Boilerplate_text] all the time, ensuring efficiency, increasing modularity and minimizing inconsistent implementation errors. Program generators and program analyzers are the two main categories of meta programs. Metaprograms can be compilers, interpreters, type checkers etc. Some commonly used applications include using a program that outputs source code to -
* generate sine/cosine/whatever lookup tables
* to extract a source-form representation of a binary file
* to compile your bitmaps into fast display routines
* to extract documentation, initialization/finalization code, description tables, as well as normal code from the same source files
* to have customized assembly code, generated from a perl/shell/scheme script that does arbitrary processing
* to propagate data defined at one point only into several cross-referencing tables and code chunks.

Programmers can focus more on the main business logic and new features to be implemented rather than writing repetitive chunks of code (e.g. setups, stubs)[1].

= Typing in Programming Languages =

Earlier programming languages [e.g. Assembly] were written such that each machine level function was reflected in the program code. With advancement in programming languages a certain level of abstraction was reached wherein lower level details were abstracted with one functional unit of work and represented by fewer lines of code e.g. primitive variables are represented with higher level abstract classes. With this abstraction arose a need for checking the validity of operations that could be performed with these abstractions in place.

Typing in programming languages is property of operations and variables in the language that ensure that certain kinds of values that are invalid are not used in operations with each other. Errors related to these are known as type errors. Type checking is the process of verifying and enforcing the constraints of types. Compile time type checking also known as static type checking. Run time type checking is known as dynamic type checking. If a language specification requires its typing rules strongly (i.e., more or less allowing only those automatic type conversions which do not lose information), one can refer to the process as strongly typed, if not, as weakly typed.[http://en.wikipedia.org/wiki/Type_system]
The above classification can be represented as -

[[Image:Meta_2.jpg]]

== Statically Typed Programming Languages ==

Statically typed languages ensure that a fixed type is assigned by the programmer to every variable and parameter. Thus, every expression type can be deduced and type checked during compilation. Static languages try to fix most errors during compile time and strive to minimize failures during run time. Due to this there are many type constraints on the programmer while coding. At run time, the program uses the classes that it has been given and in this way statically typed languages make distinctions between what happens at compile time and what happens at run time. Examples of statically typed languages are C, C++, Java, C#.

== Dynamically Typed Programming Languages ==

In dynamically typed languages, the variables and parameters do not have a designated type and may take different values at different times. In all the operations, the operands must be type checked at runtime just before performing the operation. Dynamically typed languages don’t need to make a distinction between classes created at compile time and classes provided. It is possible to define classes at run time and in fact, classes are always defined at run time. These eliminate many developer constraints by avoiding the need of book keeping, declarations etc. Due to this flexibility these languages make an ideal candidate for prototyping and are widely used in agile development environments. However, dynamic languages are known to have performance issues. Static languages have code optimization features at compile time, but dynamic languages allow runtime code optimizations only. [http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages] In dynamically typed languages, the interpreter deduces type and type conversions, this makes development time faster, but it also can provoke runtime failures. These runtime failures are caught early on during compile time for statically typed languages.
Examples of dynamically typed languages include Perl, Python, JavaScript, PHP, Ruby, Groovy.

= Metaprogramming in statically typed languages =

In safety languages [syntactically verbose], metaprogramming is not a standard feature, it can however be achieved. Also, static typing in meta-programs has a number of advantages. In addition to guaranteeing that the meta-program encounters no type-errors while manipulating object-programs, a statically typed metaprogramming language can also guarantee that any of the object-programs generated by the meta-program are also type-correct. A disadvantage of these type system is that (in case of meta-programming languages with weaker type systems) they sometime may be too restrictive in object-programs that the programmer is allowed to construct.

== Techniques and Packages ==

Many language features can be leveraged to achieve some form of characteristics needed to achieve metaprogramming. For instance, languages that support reflection also allow for dynamic code generation. e.g. In Microsoft .NET Framework use of "System.Reflection.Emit" namespace is used to generate types and methods at runtime.

=== Reflection ===

Reflection is a valuable language feature to facilitate metaprogramming. Reflection is defined as the ability of a programming language to be its own meta-language. Thus, reflection is writing programs that manipulate other programs or themselves. [http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm] 
e.g. In Java, reflection enables to discover information about the loaded classes:
* Fields,
* Methods and constructors
* Generics information
* Metadata annotations
It also enables to use these metaobjects to their instances in run time environment.
E.g. Method.invoke(Object o, Object… args)
With the Java reflection API, you can interrogate an object to get all sorts of information about its class.

Consider the following simple example:
public class HelloWorld {
public void printName() {
System.out.println(this.getClass().getName());
}
}

The line
(new HelloWorld()).printName();
sends the string HelloWorld to standard out. Now let x be an instance of HelloWorld or one of its subclasses. The line
x.printName();
sends the string naming the class to standard out.

The printName method examines the object for its class (this.getClass()). In doing so, the decision of what to print is made by delegating to the object's class. The method acts on this decision by printing the returned name. Without being overridden, the printName method behaves differently for each subclass than it does for HelloWorld. The printName method is flexible; it adapts to the class that inherits it, causing the change in behavior.

=== Annotations ===

Annotations are a metaprogramming facility that allow the code to be marked with defined tags. Many APIs require a fair amount of boilerplate code. This boilerplate could be generated automatically by a tool if the program were “decorated” with annotations indicating which methods were remotely accessible. Metadata provided using annotations is beneficial for documentation, compiler checking, and code analysis. One can use this metadata to indicate if methods are dependent on other methods, if they are incomplete, if a certain class must reference another class, and so on. It is used by the compiler to perform some basic compile-time checking. For example there is a override annotation that lets you specify that a method overrides another method from a superclass. At this, the Java compiler will ensure that the behavior you indicate in your metadata actually happens at a code level as well.

An “annotation” has an “annotation type” associated with it which is used for defining it. It is used when you want to create a custom annotation. The type is the actual construct used, and the annotation is the specific usage of that type. An annotation type definition takes an "at" (@) sign, followed by the interface keyword plus the annotation name. On the other hand, an annotation takes the form of an "at" sign (@), followed by the annotation type [http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm].

Example to Define an Annotation (Annotation type)

public @interface MyAnnotation {
String doSomething();}
Example to Annotate Your Code (Annotation)
MyAnnotation (doSomething="What to do")
public void mymethod() {
....
}

==== Annotation Types ====
There are three annotation types:
* '''Marker:''' Marker type annotations have no elements, except the annotation name itself.
Example:
public @interface MyAnnotation {
}
Usage:
@MyAnnotation
public void mymethod() {
....
}

* '''Single-Element:''' Single-element, or single-value type, annotations provide a single piece of data only. This can be represented with a data=value pair or, simply with the value (a shortcut syntax) only, within parenthesis.
Example:

public @interface MyAnnotation
{
String doSomething();
}

Usage:
@MyAnnotation ("What to do")
public void mymethod() {
....
}

* '''Full-value or multi-value:''' Full-value type annotations have multiple data members. Therefore, you must use a full data=value parameter syntax for each member.
Example:
public @interface MyAnnotation {
String doSomething();
int count; String date();
}
Usage:
@MyAnnotation (doSomething="What to do", count=1,
date="09-09-2005")
public void mymethod() {

=== Generics ===

Generic programming is a style of computer programming in which algorithms are written in terms of to-be-specified-later types that are then instantiated when needed for specific types provided as parameters. [http://en.wikipedia.org/wiki/Generic_programming] Java Generics are primarily a way for library authors to write something once, which users can customize to their own types. They allow the creation of classes and methods that work in the same way on different types of objects. The term "generic" comes from the idea that we'd like to be able to write general algorithms that can be broadly reused for many types of objects rather than having to adapt our code to fit each circumstance.

Generics add a way to specify concrete types to general purpose classes and methods that operated on object before. A Java collection is a flexible data structure that can hold heterogeneous objects where the elements may have any reference type. When you take an element out of a collection, you must cast it to the type of element that is stored in the collection. Generics provides a way for you to communicate the type of a collection to the compiler, so that it can be checked. Once the compiler knows the element type of the collection, the compiler can check that the collection has been used consistently and can insert the correct casts on values being taken out of the collection.[5] Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parametrized types (which are technically known as raw types).

Consider a non-generic example:
//This program removes 4-letter words from c. Elements must be strings
static void expurgate(Collection c)
{
for (Iterator i = c.iterator(); i.hasNext(); )
if (((String) i.next()).length() == 4)
i.remove();
}
Here is the same example modified to use generics:
//This program removes the 4-letter words from c
static void expurgate(Collection<String> c)
{
for (Iterator<String> i = c.iterator(); i.hasNext(); )
if (i.next().length() == 4)
i.remove();
}
The declaration above reads as “Collection of String c.” Collection is a generic class that takes ‘String’ as its type parameter. The code using generics is clearer and safer. Unsafe cast and a number of extra parentheses have been eliminated. More importantly, we have moved part of the specification of the method from a comment to its signature, so the compiler can verify at compile time that the type constraints are not violated at run time.[http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf]

=== Template Metaprogramming ===
Template metaprogramming(TMP) or Static Metaprogramming is a technique that allows the execution of programs at compile-time. It uses extremely early binding.
A primary requirement for a metaprogramming language is providing high-level abstractions to hide the internal representation of base programs.[http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf] Each template language is specific for a base language and is generated from it. In this sense, a language of templates is a superset of the base language. Thus templates are abstractions that encapsulate a program pattern written by example. This concept has been explained in detail in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#C.2B.2B_Template_Metaprogramming section 3.2.5]

Uses of template metaprogramming:
* Compile-time dimensional analysis
* Multiple dispatch
* Design patterns
* Code optimization
* Lexing and parsing

== Packages ==

=== Javassist (Java Programming Assistant) ===

Javassist is a Java library providing means to manipulate the Java bytecode of an application. It provides the support for structural reflection, i.e. the ability to change the implementation of a class at runtime. [http://www.csg.is.titech.ac.jp/~chiba/javassist/] Javassist is explicit metaprogramming, in which the metalanguage is Java. It is a load-time reflective system for Java which enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it. Unlike other similar bytecode editors, Javassist provides two levels of API: source level and bytecode level.

If the users use the source-level API, they can edit a class file without knowledge of the specifications of the Java bytecode. They do not have to even write an inserted bytecode sequence; Javassist instead can compile a fragment of source text on line (for example, just a single statement). This ease of use is a unique feature of Javassit against other tools. One can even specify inserted bytecode in the form of source text and Javassist compiles it on the fly. On the other hand, the bytecode-level API allows the users to directly edit a class file as other editors. Thus it makes Java bytecode manipulation simple.

Javassist has the following applications:
* Aspect Oriented Programming: Javassist can be a good tool for introducing new methods into a class and for inserting before/after/around advice at the both caller and callee sides.
* Reflection: One of applications of Javassist is runtime reflection; Javassist enables Java programs to use a metaobject that controls method calls on base-level objects. No specialized compiler or virtual machine are needed.
* Remote method invocation: Another application is remote method invocation. Javassist enables applets to call a method on a remote object running on the web server. Unlike the Java RMI, the programmer does notneed a stub compiler such as rmic; the stub code is dynamically produced by Javassist.

Example:
BufferedInputStream fin = new BufferedInputStream(new FileInputStream("Point.class"));
ClassFile cf = new ClassFile(new DataInputStream(fin));

A ClassFile object can be written back to a class file. write() in ClassFile writes the contents of the class file to a given DataOutputStream. ClassFile provides addField() and addMethod() for adding a field or a method (note that a constructor is regarded as a method at the bytecode level). It also provides addAttribute() for adding an attribute to the class file.

To examine every bytecode instruction in a method body, CodeIterator is useful. A CodeIterator object allows you to visit every bytecode instruction one by one from the beginning to the end. To otbain this object, do as follows:

ClassFile cf = ... ;
MethodInfo minfo = cf.getMethod("move"); // we assume move is not overloaded.
CodeAttribute ca = minfo.getCodeAttribute();
CodeIterator i = ca.iterator();

Other extensions are being developed to include reflective systems for C++ and Java e.g. OpenC++ and OpenJava which are extensible preprocessors based on compile-time reflection in C++ and Java respectively.

=== JRuby ===

JRuby is a complete implementation of Ruby in Java. The scripting and functional features of the Ruby language can be used by Java developers.[http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules] Simple metaprogramming techniques can be extended from Ruby so that Java packages are mapped onto to Ruby modules. This would be something like a Ruby-Java Bridge, since JRuby can be run from any platform with a JVM.

Example:
Using JRuby API calling JRuby from Java

import org.jruby.*;
public class SimpleJRubyCall {
public static void main(String[] args) {
Ruby runtime = Ruby.getDefaultInstance();
runtime.evalScript(“puts 1+2”);
}
}

With metaprogramming using JRuby one can
* add methods to class,
* add instance methods
* add to have Java classes

Since metaprogramming empowers the programmer to create domain specific languages(DSL), the ones created by JRuby can always leverage Java libraries to build wrapper functionalities.
e.g. Simple JRuby DSL on top of HtmlUnit

=== AspectJ ===
Another library worth mentioning here is AspectJ. It enforces the aspect oriented programming (AOP) approach in Java. Aspect oriented programming is a complimentary programming paradigm to object oriented programming and is used to improve the modularity of software systems. Thus, while object oriented programming is great for modeling common behavior on a hierarchy of objects, aspect oriented programming allows you to define cross-cutting concerns by adding direct semantics and can be applied across heterogeneous object models. [http://static.springsource.org/spring/docs/2.0.x/reference/aop.html] Applications of aspect oriented programming include logging, instrumenting and debugging.

In object oriented programs, the natural unit of modularity is the class. In AspectJ, aspects modularize concerns that affect more than one class. In addition to classes, aspect oriented programming uses 'aspects'. Aspects enable modularization of crosscutting concerns such as transaction management that cut across multiple types and objects. Thus, AspectJ package achieves metaprogramming features with more controllability.

AspectJ introduces declaring aspects in the statically typed language Java by using 3 key concepts -
* Join Points - well defined points in program execution
* Advice - defines additional code to be executed around join points
* Pointcut - define those points in the source code of a program where an advice will be applied

The core task of AspectJ's advice weaver is to statically transform a program so that at runtime it will behave according to the AspectJ language semantics. The AspectJ weaver takes class files as input and produces class files as output. The weaving process itself can take place at one of three different times: compile-time, post-compile time, and load-time. These two java files are 'woven' together by compiler i.e. the class and the aspect behavior are tied together. This is also known as 'plugging-in' the aspect. [http://oreilly.com/catalog/9780596006549]

Example - Simple tracing/logging

Consider the HelloWorld class below which implements an application that simply displays "Hello World!" on the standard output.
package helloworld;
class HelloWorld {
public static void main(String[] args) {
new HelloWorld().printMessage();
}
void printMessage() {
System.out.println("Hello world!");
}
}

Consider another Java source file with an aspect definition as follows -
package helloworld;
aspect Trace of eachobject(instanceof(HelloWorld)) {
pointcut printouts(): receptions(void printMessage());
before(): printouts() {
System.out.println("*** Entering printMessage ***");
}
after(): printouts() {
System.out.println("*** Exiting printMessage ***");
}
}

In above example, the Trace aspect injects tracing messages before and after method main of class HelloWorld. If one does not want tracing, one can simply leave the aspect out and plug it in as and when required.

In contrast to reflection[low level], AspectJ provides more carefully controlled power, drawing on the rules learned from object-oriented development to encourage a clean and understandable program structure. An aspect imposes behavior on a class, rather than a class requesting behavior from an aspect. An aspect can modify a class without needing to edit that class - also known as 'reverse inheritance'.

=== MetaJ ===

MetaJ is another package that supports metaprogramming in the Java language. A MetaJ program consists of the Java code with special metaprogramming declarations that will control how the output code is created. It uses templates and reflection. Templates are abstractions that encapsulate a program pattern written by example. Templates are translated to Java classes, so they can be accessed in the metaprogram. Accessing patterns by example inside ordinary Java programs is a major feature of MetaJ programming. [http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment]

Language Dependency:
MetaJ comprises of a set of concepts that are independent of the base language. These are syntax trees, code references, code iterators and code templates. A framework is defined which in which features common to most languages are abstracted. This supports independence from base language. Thus, generic operations can be defined and components that are language dependent can be plugged onto it.

Execution Flow Representation:

[[Image:Meta_3.jpg]]

Example:

Template : SampleTempl

package myTempl;
language = Java // base language plugin
template #CompilationUnit SampleTempl{
#[#PackageDeclaration:pck]#
#[#ImportDeclarationList:imps]#
class SampleTempl { ... }
#TypeDeclaration:td
}

Instance of Template : Java Code

package myTempl;
import metaj.framework.AbstractTemplate;
public class SampleTempl extends AbstractTemplate{
public final Reference imps, td, pck;
... // Implementation of superclass abstract methods
}

Java SDK7 has added support for dynamic typing and metaprogramming and includes MetaJ implementation.

=== C++ Template Metaprogramming ===

In C++, [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#Template_Metaprogramming static metaprogramming] is implemented with the help of reflection. The most important implementation of reflection in C++ is using the feature of run time type-identification (RTTI) [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules]. RTTI is a system that keeps information about an object's data type in memory at run time. Run-time type information can apply to simple data types, such as integers and characters, or to generic objects. Enabling RTTI in C++ allows the use of dynamic_cast<> operation, the typeid operator or exceptions [http://en.wikipedia.org/wiki/Run-time_type_information].

The template mechanism in C++ allows defining parametrized classes and functions. Templates together with other C++ features constitute a Turing-complete, compile-time sub- language of C++. A Turing-complete language is a language with at least a conditional and a looping construct. C++ can be considered to be a two-level language since a C++ program may contain both static code, which is evaluated at compile time, and dynamic code, which is executed at run time. Template meta-programs are the part of a C++ source that is executed during compilation. A meta-program can access information about types not generally available to ordinary programs [http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf].

Given below is an example of how to use templates for writing a common recursive factorial program:
template<int count>
class FACTOR{
public:
enum {RESULT = count * FACTOR<count-1>::RESULT};
};
class FACTOR<1>{
public:
enum {RESULT = 1};
};

If we write this-
int j = FACTOR<5>::RESULT;

The above line will calculate the value of 5 factorial. As we instantiate FACTOR<5> the definition of this class depends on FACTOR<4>, which in turn depend on FACTOR<3> and so on. The compiler needs to create all these classes until the template specialization FACTOR<1> is reached. This means the entire recursion is done by the compiler during compile time and it uses the result as if it is a constant.

= Conclusion =

Dynamically typed languages are best suited to provide support for metaprogramming due to their inherent nature of easily overcoming distinction between code and data e.g. Lisp provides this feature of interchangeability. Code and data are both represented in Lisp as lists, so any list can easily be treated as either code or data.
It’s simple, therefore, to manipulate code as data, and then execute it – either via EVAL or by returning it as the result of a macro expansion. [3]

Thus, statically typed languages achieve metaprogramming using various techniques and tools to achieve the level of flexibility that dynamic languages provide immanently.

= References and Notes =

*[1] [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming]
*[2] [http://en.wikipedia.org/wiki/Boilerplate_text Boilerplate Text]
*[3] [http://en.wikipedia.org/wiki/Type_system Type System]
*[4] [http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages Bandeali, M. 2009. ''Dynamically and Statically typed languages'']
*[5] [http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm Java Reflection in Action]
*[6] [http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm An Introduction to Java Annotations]
*[7] [http://en.wikipedia.org/wiki/Generic_programming Generic Programming]
*[8] [http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf Haapakorpi, M. ''Metaprogramming in Java'']
*[9] [http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf Attardi, G., Cisternino, A. ''Reflection support by means of template metaprogramming'']
*[10] [http://www.csg.is.titech.ac.jp/~chiba/javassist/ Javassist]
*[11] [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules Metaprogramming with Ruby: Mapping Java Packages Onto Ruby Modules]
*[12] [http://static.springsource.org/spring/docs/2.0.x/reference/aop.html Aspect Oriented Programming with Spring]
*[13] [http://oreilly.com/catalog/9780596006549 Miles, R. 2004 ''AspectJ Cookbook'' O'Reilly Media]
*[14] [http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment Oliveira, A.A., Braga, T.H, Maia, M.A., Bigonha and R.S. 2004. MetaJ: An Extensible Environment for Metaprogramming in Java, ''Journal of Universal Computer Science, vol. 10, no. 7 (2004), 872-891'']
*[15] [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules Metaprogramming with Ruby: Mapping Java Packages Onto Ruby Modules ]
*[16] [http://en.wikipedia.org/wiki/Run-time_type_information Run-time Type Information]

= Further Reading =

*[http://www.cs.tut.fi/~kk/webstuff/MetaprogrammingCpp.pdf Metaprogramming in C++]
*[http://en.wikipedia.org/wiki/Automatic_programming Automatic/Generative Programming]
*[http://www.slideshare.net/dogangoko/new-features-of-java7-se-presentation News in the upcoming Java 7]

CSC/ECE 517 Fall 2010/ch2 S24 rm

2010-10-01T00:08:29Z

Whiteopal: /* References and Notes */

'''Metaprogramming in Statically Typed Languages'''

''"I'd rather write programs that write programs than write programs" - Richard Sites''

__TOC__

= Introduction =

Metaprogramming is an inherent feature of dynamically typed languages [e.g. Ruby]. However, achieving metaprogramming in statically typed languages [e.g. Java] becomes complex due to compile time abstraction verification. In this topic, we explore how tools and packages are usedto implement metaprogramming in statically typed languages .

== Metaprogramming ==

Metaprogramming is a programming technique of writing computer programs that write or manipulate other programs or themselves, as data. [http://en.wikipedia.org/wiki/Metaprogramming] In other words, it is a programming technique of writing programs with a higher level of abstraction to make it appear as generative programming.

Metaprogramming involves two kinds of languages-
* '''Meta-language''' is the language in which meta-programs, which construct or manipulate other programs, are written.
* '''Object-language''' is the language of programs being manipulated.
This makes them ‘meta level programs’ whose problem domain are other ‘base level programs’.

[[Image:Meta_1.jpg]]

The ability of a programming language to be its own metalanguage is called reflection or reflexivity.

Simple example of a metaprogram:
 Let us consider a totally fabricated example for our understanding at very high level. Suppose we need to write a C program that printed the following 500 lines of text with a restriction that the program could not use any kind of loop or goto instruction.

Output expected:

1 Mississippi
2 Mississippi
3 Mississippi
4 Mississippi
...
499 Mississippi
500 Mississippi

In C this would be then coded as:

#include <stdio.h>
int main(void) {
printf("1 Mississippi\n");
printf("2 Mississippi\n");
-
-
-
printf("499 Mississippi\n");
printf("500 Mississippi\n");
return 0;
}

With the power of a metaprogramming language we can write another program that writes this program automatically.

Ruby code:

File.open('mississippi.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(500) do |i|
output.puts " printf(\"#{i} " +
"Mississippi\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called mississippi.c with the expected 500+ lines of C source code.Here, mississippi.c is the generated code and ruby code is the metaprogram.

== Applications of Metaprogramming ==

Metaprogramming is an attractive technique needed when one needs to alter the behavior of a program at run time. Due to its generative nature, it has numerous applications in program development. It can achieve program development without rewriting boiler-plate code [http://en.wikipedia.org/wiki/Boilerplate_text] all the time, ensuring efficiency, increasing modularity and minimizing inconsistent implementation errors. Program generators and program analyzers are the two main categories of meta programs. Metaprograms can be compilers, interpreters, type checkers etc. Some commonly used applications include using a program that outputs source code to -
* generate sine/cosine/whatever lookup tables
* to extract a source-form representation of a binary file
* to compile your bitmaps into fast display routines
* to extract documentation, initialization/finalization code, description tables, as well as normal code from the same source files
* to have customized assembly code, generated from a perl/shell/scheme script that does arbitrary processing
* to propagate data defined at one point only into several cross-referencing tables and code chunks.

Programmers can focus more on the main business logic and new features to be implemented rather than writing repetitive chunks of code (e.g. setups, stubs)[1].

= Typing in Programming Languages =

Earlier programming languages [e.g. Assembly] were written such that each machine level function was reflected in the program code. With advancement in programming languages a certain level of abstraction was reached wherein lower level details were abstracted with one functional unit of work and represented by fewer lines of code e.g. primitive variables are represented with higher level abstract classes. With this abstraction arose a need for checking the validity of operations that could be performed with these abstractions in place.

Typing in programming languages is property of operations and variables in the language that ensure that certain kinds of values that are invalid are not used in operations with each other. Errors related to these are known as type errors. Type checking is the process of verifying and enforcing the constraints of types. Compile time type checking also known as static type checking. Run time type checking is known as dynamic type checking. If a language specification requires its typing rules strongly (i.e., more or less allowing only those automatic type conversions which do not lose information), one can refer to the process as strongly typed, if not, as weakly typed.[http://en.wikipedia.org/wiki/Type_system]
The above classification can be represented as -

[[Image:Meta_2.jpg]]

== Statically Typed Programming Languages ==

Statically typed languages ensure that a fixed type is assigned by the programmer to every variable and parameter. Thus, every expression type can be deduced and type checked during compilation. Static languages try to fix most errors during compile time and strive to minimize failures during run time. Due to this there are many type constraints on the programmer while coding. At run time, the program uses the classes that it has been given and in this way statically typed languages make distinctions between what happens at compile time and what happens at run time. Examples of statically typed languages are C, C++, Java, C#.

== Dynamically Typed Programming Languages ==

In dynamically typed languages, the variables and parameters do not have a designated type and may take different values at different times. In all the operations, the operands must be type checked at runtime just before performing the operation. Dynamically typed languages don’t need to make a distinction between classes created at compile time and classes provided. It is possible to define classes at run time and in fact, classes are always defined at run time. These eliminate many developer constraints by avoiding the need of book keeping, declarations etc. Due to this flexibility these languages make an ideal candidate for prototyping and are widely used in agile development environments. However, dynamic languages are known to have performance issues. Static languages have code optimization features at compile time, but dynamic languages allow runtime code optimizations only. [http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages] In dynamically typed languages, the interpreter deduces type and type conversions, this makes development time faster, but it also can provoke runtime failures. These runtime failures are caught early on during compile time for statically typed languages.
Examples of dynamically typed languages include Perl, Python, JavaScript, PHP, Ruby, Groovy.

= Metaprogramming in statically typed languages =

In safety languages [syntactically verbose], metaprogramming is not a standard feature, it can however be achieved. Also, static typing in meta-programs has a number of advantages. In addition to guaranteeing that the meta-program encounters no type-errors while manipulating object-programs, a statically typed metaprogramming language can also guarantee that any of the object-programs generated by the meta-program are also type-correct. A disadvantage of these type system is that (in case of meta-programming languages with weaker type systems) they sometime may be too restrictive in object-programs that the programmer is allowed to construct.

== Techniques and Packages ==

Many language features can be leveraged to achieve some form of characteristics needed to achieve metaprogramming. For instance, languages that support reflection also allow for dynamic code generation. e.g. In Microsoft .NET Framework use of "System.Reflection.Emit" namespace is used to generate types and methods at runtime.

=== Reflection ===

Reflection is a valuable language feature to facilitate metaprogramming. Reflection is defined as the ability of a programming language to be its own meta-language. Thus, reflection is writing programs that manipulate other programs or themselves. [http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm] 
e.g. In Java, reflection enables to discover information about the loaded classes:
* Fields,
* Methods and constructors
* Generics information
* Metadata annotations
It also enables to use these metaobjects to their instances in run time environment.
E.g. Method.invoke(Object o, Object… args)
With the Java reflection API, you can interrogate an object to get all sorts of information about its class.

Consider the following simple example:
public class HelloWorld {
public void printName() {
System.out.println(this.getClass().getName());
}
}

The line
(new HelloWorld()).printName();
sends the string HelloWorld to standard out. Now let x be an instance of HelloWorld or one of its subclasses. The line
x.printName();
sends the string naming the class to standard out.

The printName method examines the object for its class (this.getClass()). In doing so, the decision of what to print is made by delegating to the object's class. The method acts on this decision by printing the returned name. Without being overridden, the printName method behaves differently for each subclass than it does for HelloWorld. The printName method is flexible; it adapts to the class that inherits it, causing the change in behavior.

=== Annotations ===

Annotations are a metaprogramming facility that allow the code to be marked with defined tags. Many APIs require a fair amount of boilerplate code. This boilerplate could be generated automatically by a tool if the program were “decorated” with annotations indicating which methods were remotely accessible. Metadata provided using annotations is beneficial for documentation, compiler checking, and code analysis. One can use this metadata to indicate if methods are dependent on other methods, if they are incomplete, if a certain class must reference another class, and so on. It is used by the compiler to perform some basic compile-time checking. For example there is a override annotation that lets you specify that a method overrides another method from a superclass. At this, the Java compiler will ensure that the behavior you indicate in your metadata actually happens at a code level as well.

An “annotation” has an “annotation type” associated with it which is used for defining it. It is used when you want to create a custom annotation. The type is the actual construct used, and the annotation is the specific usage of that type. An annotation type definition takes an "at" (@) sign, followed by the interface keyword plus the annotation name. On the other hand, an annotation takes the form of an "at" sign (@), followed by the annotation type [http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm].

Example to Define an Annotation (Annotation type)

public @interface MyAnnotation {
String doSomething();}
Example to Annotate Your Code (Annotation)
MyAnnotation (doSomething="What to do")
public void mymethod() {
....
}

==== Annotation Types ====
There are three annotation types:
* '''Marker:''' Marker type annotations have no elements, except the annotation name itself.
Example:
public @interface MyAnnotation {
}
Usage:
@MyAnnotation
public void mymethod() {
....
}

* '''Single-Element:''' Single-element, or single-value type, annotations provide a single piece of data only. This can be represented with a data=value pair or, simply with the value (a shortcut syntax) only, within parenthesis.
Example:

public @interface MyAnnotation
{
String doSomething();
}

Usage:
@MyAnnotation ("What to do")
public void mymethod() {
....
}

* '''Full-value or multi-value:''' Full-value type annotations have multiple data members. Therefore, you must use a full data=value parameter syntax for each member.
Example:
public @interface MyAnnotation {
String doSomething();
int count; String date();
}
Usage:
@MyAnnotation (doSomething="What to do", count=1,
date="09-09-2005")
public void mymethod() {

=== Generics ===

Generic programming is a style of computer programming in which algorithms are written in terms of to-be-specified-later types that are then instantiated when needed for specific types provided as parameters. [http://en.wikipedia.org/wiki/Generic_programming] Java Generics are primarily a way for library authors to write something once, which users can customize to their own types. They allow the creation of classes and methods that work in the same way on different types of objects. The term "generic" comes from the idea that we'd like to be able to write general algorithms that can be broadly reused for many types of objects rather than having to adapt our code to fit each circumstance.

Generics add a way to specify concrete types to general purpose classes and methods that operated on object before. A Java collection is a flexible data structure that can hold heterogeneous objects where the elements may have any reference type. When you take an element out of a collection, you must cast it to the type of element that is stored in the collection. Generics provides a way for you to communicate the type of a collection to the compiler, so that it can be checked. Once the compiler knows the element type of the collection, the compiler can check that the collection has been used consistently and can insert the correct casts on values being taken out of the collection.[5] Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parametrized types (which are technically known as raw types).

Consider a non-generic example:
//This program removes 4-letter words from c. Elements must be strings
static void expurgate(Collection c)
{
for (Iterator i = c.iterator(); i.hasNext(); )
if (((String) i.next()).length() == 4)
i.remove();
}
Here is the same example modified to use generics:
//This program removes the 4-letter words from c
static void expurgate(Collection<String> c)
{
for (Iterator<String> i = c.iterator(); i.hasNext(); )
if (i.next().length() == 4)
i.remove();
}
The declaration above reads as “Collection of String c.” Collection is a generic class that takes ‘String’ as its type parameter. The code using generics is clearer and safer. Unsafe cast and a number of extra parentheses have been eliminated. More importantly, we have moved part of the specification of the method from a comment to its signature, so the compiler can verify at compile time that the type constraints are not violated at run time.[http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf]

=== Template Metaprogramming ===
Template metaprogramming(TMP) or Static Metaprogramming is a technique that allows the execution of programs at compile-time. It uses extremely early binding.
A primary requirement for a metaprogramming language is providing high-level abstractions to hide the internal representation of base programs.[http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf] Each template language is specific for a base language and is generated from it. In this sense, a language of templates is a superset of the base language. Thus templates are abstractions that encapsulate a program pattern written by example. This concept has been explained in detail in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#C.2B.2B_Template_Metaprogramming section 3.2.5]

Uses of template metaprogramming:
* Compile-time dimensional analysis
* Multiple dispatch
* Design patterns
* Code optimization
* Lexing and parsing

== Packages ==

=== Javassist (Java Programming Assistant) ===

Javassist is a Java library providing means to manipulate the Java bytecode of an application. It provides the support for structural reflection, i.e. the ability to change the implementation of a class at runtime. [http://www.csg.is.titech.ac.jp/~chiba/javassist/] Javassist is explicit metaprogramming, in which the metalanguage is Java. It is a load-time reflective system for Java which enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it. Unlike other similar bytecode editors, Javassist provides two levels of API: source level and bytecode level.

If the users use the source-level API, they can edit a class file without knowledge of the specifications of the Java bytecode. They do not have to even write an inserted bytecode sequence; Javassist instead can compile a fragment of source text on line (for example, just a single statement). This ease of use is a unique feature of Javassit against other tools. One can even specify inserted bytecode in the form of source text and Javassist compiles it on the fly. On the other hand, the bytecode-level API allows the users to directly edit a class file as other editors. Thus it makes Java bytecode manipulation simple.

Javassist has the following applications:
* Aspect Oriented Programming: Javassist can be a good tool for introducing new methods into a class and for inserting before/after/around advice at the both caller and callee sides.
* Reflection: One of applications of Javassist is runtime reflection; Javassist enables Java programs to use a metaobject that controls method calls on base-level objects. No specialized compiler or virtual machine are needed.
* Remote method invocation: Another application is remote method invocation. Javassist enables applets to call a method on a remote object running on the web server. Unlike the Java RMI, the programmer does notneed a stub compiler such as rmic; the stub code is dynamically produced by Javassist.

Example:
BufferedInputStream fin = new BufferedInputStream(new FileInputStream("Point.class"));
ClassFile cf = new ClassFile(new DataInputStream(fin));

A ClassFile object can be written back to a class file. write() in ClassFile writes the contents of the class file to a given DataOutputStream. ClassFile provides addField() and addMethod() for adding a field or a method (note that a constructor is regarded as a method at the bytecode level). It also provides addAttribute() for adding an attribute to the class file.

To examine every bytecode instruction in a method body, CodeIterator is useful. A CodeIterator object allows you to visit every bytecode instruction one by one from the beginning to the end. To otbain this object, do as follows:

ClassFile cf = ... ;
MethodInfo minfo = cf.getMethod("move"); // we assume move is not overloaded.
CodeAttribute ca = minfo.getCodeAttribute();
CodeIterator i = ca.iterator();

Other extensions are being developed to include reflective systems for C++ and Java e.g. OpenC++ and OpenJava which are extensible preprocessors based on compile-time reflection in C++ and Java respectively.

=== JRuby ===

JRuby is a complete implementation of Ruby in Java. The scripting and functional features of the Ruby language can be used by Java developers.[http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules] Simple metaprogramming techniques can be extended from Ruby so that Java packages are mapped onto to Ruby modules. This would be something like a Ruby-Java Bridge, since JRuby can be run from any platform with a JVM.

Example:
Using JRuby API calling JRuby from Java

import org.jruby.*;
public class SimpleJRubyCall {
public static void main(String[] args) {
Ruby runtime = Ruby.getDefaultInstance();
runtime.evalScript(“puts 1+2”);
}
}

With metaprogramming using JRuby one can
* add methods to class,
* add instance methods
* add to have Java classes

Since metaprogramming empowers the programmer to create domain specific languages(DSL), the ones created by JRuby can always leverage Java libraries to build wrapper functionalities.
e.g. Simple JRuby DSL on top of HtmlUnit

=== AspectJ ===
Another library worth mentioning here is AspectJ. It enforces the aspect oriented programming (AOP) approach in Java. Aspect oriented programming is a complimentary programming paradigm to object oriented programming and is used to improve the modularity of software systems. Thus, while object oriented programming is great for modeling common behavior on a hierarchy of objects, aspect oriented programming allows you to define cross-cutting concerns by adding direct semantics and can be applied across heterogeneous object models. [http://static.springsource.org/spring/docs/2.0.x/reference/aop.html] Applications of aspect oriented programming include logging, instrumenting and debugging.

In object oriented programs, the natural unit of modularity is the class. In AspectJ, aspects modularize concerns that affect more than one class. In addition to classes, aspect oriented programming uses 'aspects'. Aspects enable modularization of crosscutting concerns such as transaction management that cut across multiple types and objects. Thus, AspectJ package achieves metaprogramming features with more controllability.

AspectJ introduces declaring aspects in the statically typed language Java by using 3 key concepts -
* Join Points - well defined points in program execution
* Advice - defines additional code to be executed around join points
* Pointcut - define those points in the source code of a program where an advice will be applied

The core task of AspectJ's advice weaver is to statically transform a program so that at runtime it will behave according to the AspectJ language semantics. The AspectJ weaver takes class files as input and produces class files as output. The weaving process itself can take place at one of three different times: compile-time, post-compile time, and load-time. These two java files are 'woven' together by compiler i.e. the class and the aspect behavior are tied together. This is also known as 'plugging-in' the aspect. [http://oreilly.com/catalog/9780596006549]

Example - Simple tracing/logging

Consider the HelloWorld class below which implements an application that simply displays "Hello World!" on the standard output.
package helloworld;
class HelloWorld {
public static void main(String[] args) {
new HelloWorld().printMessage();
}
void printMessage() {
System.out.println("Hello world!");
}
}

Consider another Java source file with an aspect definition as follows -
package helloworld;
aspect Trace of eachobject(instanceof(HelloWorld)) {
pointcut printouts(): receptions(void printMessage());
before(): printouts() {
System.out.println("*** Entering printMessage ***");
}
after(): printouts() {
System.out.println("*** Exiting printMessage ***");
}
}

In above example, the Trace aspect injects tracing messages before and after method main of class HelloWorld. If one does not want tracing, one can simply leave the aspect out and plug it in as and when required.

In contrast to reflection[low level], AspectJ provides more carefully controlled power, drawing on the rules learned from object-oriented development to encourage a clean and understandable program structure. An aspect imposes behavior on a class, rather than a class requesting behavior from an aspect. An aspect can modify a class without needing to edit that class - also known as 'reverse inheritance'.

=== MetaJ ===

MetaJ is another package that supports metaprogramming in the Java language. A MetaJ program consists of the Java code with special metaprogramming declarations that will control how the output code is created. It uses templates and reflection. Templates are abstractions that encapsulate a program pattern written by example. Templates are translated to Java classes, so they can be accessed in the metaprogram. Accessing patterns by example inside ordinary Java programs is a major feature of MetaJ programming. [http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment]

Language Dependency:
MetaJ comprises of a set of concepts that are independent of the base language. These are syntax trees, code references, code iterators and code templates. A framework is defined which in which features common to most languages are abstracted. This supports independence from base language. Thus, generic operations can be defined and components that are language dependent can be plugged onto it.

Execution Flow Representation:

[[Image:Meta_3.jpg]]

Example:

Template : SampleTempl

package myTempl;
language = Java // base language plugin
template #CompilationUnit SampleTempl{
#[#PackageDeclaration:pck]#
#[#ImportDeclarationList:imps]#
class SampleTempl { ... }
#TypeDeclaration:td
}

Instance of Template : Java Code

package myTempl;
import metaj.framework.AbstractTemplate;
public class SampleTempl extends AbstractTemplate{
public final Reference imps, td, pck;
... // Implementation of superclass abstract methods
}

Java SDK7 has added support for dynamic typing and metaprogramming and includes MetaJ implementation.

=== C++ Template Metaprogramming ===

In C++, [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#Template_Metaprogramming static metaprogramming] is implemented with the help of reflection. The most important implementation of reflection in C++ is using the feature of run time type-identification (RTTI) [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules]. RTTI is a system that keeps information about an object's data type in memory at run time. Run-time type information can apply to simple data types, such as integers and characters, or to generic objects. Enabling RTTI in C++ allows the use of dynamic_cast<> operation, the typeid operator or exceptions [http://en.wikipedia.org/wiki/Run-time_type_information].

The template mechanism in C++ allows defining parametrized classes and functions. Templates together with other C++ features constitute a Turing-complete, compile-time sub- language of C++. A Turing-complete language is a language with at least a conditional and a looping construct. C++ can be considered to be a two-level language since a C++ program may contain both static code, which is evaluated at compile time, and dynamic code, which is executed at run time. Template meta-programs are the part of a C++ source that is executed during compilation. A meta-program can access information about types not generally available to ordinary programs [http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf].

Given below is an example of how to use templates for writing a common recursive factorial program:
template<int count>
class FACTOR{
public:
enum {RESULT = count * FACTOR<count-1>::RESULT};
};
class FACTOR<1>{
public:
enum {RESULT = 1};
};

If we write this-
int j = FACTOR<5>::RESULT;

The above line will calculate the value of 5 factorial. As we instantiate FACTOR<5> the definition of this class depends on FACTOR<4>, which in turn depend on FACTOR<3> and so on. The compiler needs to create all these classes until the template specialization FACTOR<1> is reached. This means the entire recursion is done by the compiler during compile time and it uses the result as if it is a constant.

= Conclusion =

Dynamically typed languages are best suited to provide support for metaprogramming due to their inherent nature of easily overcoming distinction between code and data e.g. Lisp provides this feature of interchangeability. Code and data are both represented in Lisp as lists, so any list can easily be treated as either code or data.
It’s simple, therefore, to manipulate code as data, and then execute it – either via EVAL or by returning it as the result of a macro expansion. [3]

Thus, statically typed languages achieve metaprogramming using various techniques and tools to achieve the level of flexibility that dynamic languages provide immanently.

= References and Notes =

*[1] [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming]
*[2] [http://en.wikipedia.org/wiki/Boilerplate_text Boilerplate Text]
*[3] [http://en.wikipedia.org/wiki/Type_system Type System]
*[4] [http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages Bandeali, M. 2009. ''Dynamically and Statically typed languages'']
*[5] [http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm Java Reflection in Action]
*[6] [http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm An Introduction to Java Annotations]
*[7] [http://en.wikipedia.org/wiki/Generic_programming Generic Programming]
*[8] [http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf Haapakorpi, M. ''Metaprogramming in Java'']
*[9] [http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf Attardi, G., Cisternino, A. ''Reflection support by means of template metaprogramming'']
*[10] [http://www.csg.is.titech.ac.jp/~chiba/javassist/ Javassist]
*[11] [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules Metaprogramming with Ruby: Mapping Java Packages Onto Ruby Modules]
*[12] [http://static.springsource.org/spring/docs/2.0.x/reference/aop.html Aspect Oriented Programming with Spring]
*[13] [http://oreilly.com/catalog/9780596006549 Miles, R. 2004 ''AspectJ Cookbook'' O'Reilly Media]
*[14] [http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment Oliveira, A.A., Braga, T.H, Maia, M.A., Bigonha and R.S. 2004. MetaJ: An Extensible Environment for Metaprogramming in Java, ''Journal of Universal Computer Science, vol. 10, no. 7 (2004), 872-891''
*[15] http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules
*[16] http://en.wikipedia.org/wiki/Run-time_type_information
*[17] http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf

= Further Reading =

*[http://www.cs.tut.fi/~kk/webstuff/MetaprogrammingCpp.pdf Metaprogramming in C++]
*[http://en.wikipedia.org/wiki/Automatic_programming Automatic/Generative Programming]
*[http://www.slideshare.net/dogangoko/new-features-of-java7-se-presentation News in the upcoming Java 7]

CSC/ECE 517 Fall 2010/ch2 S24 rm

2010-09-30T23:37:21Z

Whiteopal:

'''Metaprogramming in Statically Typed Languages'''

''"I'd rather write programs that write programs than write programs" - Richard Sites''

__TOC__

= Introduction =

Metaprogramming is an inherent feature of dynamically typed languages [e.g. Ruby]. However, achieving metaprogramming in statically typed languages [e.g. Java] becomes complex due to compile time abstraction verification. In this topic, we explore how tools and packages are usedto implement metaprogramming in statically typed languages .

== Metaprogramming ==

Metaprogramming is a programming technique of writing computer programs that write or manipulate other programs or themselves, as data. [http://en.wikipedia.org/wiki/Metaprogramming] In other words, it is a programming technique of writing programs with a higher level of abstraction to make it appear as generative programming.

Metaprogramming involves two kinds of languages-
* '''Meta-language''' is the language in which meta-programs, which construct or manipulate other programs, are written.
* '''Object-language''' is the language of programs being manipulated.
This makes them ‘meta level programs’ whose problem domain are other ‘base level programs’.

[[Image:Meta_1.jpg]]

The ability of a programming language to be its own metalanguage is called reflection or reflexivity.

Simple example of a metaprogram:
 Let us consider a totally fabricated example for our understanding at very high level. Suppose we need to write a C program that printed the following 500 lines of text with a restriction that the program could not use any kind of loop or goto instruction.

Output expected:

1 Mississippi
2 Mississippi
3 Mississippi
4 Mississippi
...
499 Mississippi
500 Mississippi

In C this would be then coded as:

#include <stdio.h>
int main(void) {
printf("1 Mississippi\n");
printf("2 Mississippi\n");
-
-
-
printf("499 Mississippi\n");
printf("500 Mississippi\n");
return 0;
}

With the power of a metaprogramming language we can write another program that writes this program automatically.

Ruby code:

File.open('mississippi.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(500) do |i|
output.puts " printf(\"#{i} " +
"Mississippi\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called mississippi.c with the expected 500+ lines of C source code.Here, mississippi.c is the generated code and ruby code is the metaprogram.

== Applications of Metaprogramming ==

Metaprogramming is an attractive technique needed when one needs to alter the behavior of a program at run time. Due to its generative nature, it has numerous applications in program development. It can achieve program development without rewriting boiler-plate code [http://en.wikipedia.org/wiki/Boilerplate_text] all the time, ensuring efficiency, increasing modularity and minimizing inconsistent implementation errors. Program generators and program analyzers are the two main categories of meta programs. Metaprograms can be compilers, interpreters, type checkers etc. Some commonly used applications include using a program that outputs source code to -
* generate sine/cosine/whatever lookup tables
* to extract a source-form representation of a binary file
* to compile your bitmaps into fast display routines
* to extract documentation, initialization/finalization code, description tables, as well as normal code from the same source files
* to have customized assembly code, generated from a perl/shell/scheme script that does arbitrary processing
* to propagate data defined at one point only into several cross-referencing tables and code chunks.

Programmers can focus more on the main business logic and new features to be implemented rather than writing repetitive chunks of code (e.g. setups, stubs)[1].

= Typing in Programming Languages =

Earlier programming languages [e.g. Assembly] were written such that each machine level function was reflected in the program code. With advancement in programming languages a certain level of abstraction was reached wherein lower level details were abstracted with one functional unit of work and represented by fewer lines of code e.g. primitive variables are represented with higher level abstract classes. With this abstraction arose a need for checking the validity of operations that could be performed with these abstractions in place.

Typing in programming languages is property of operations and variables in the language that ensure that certain kinds of values that are invalid are not used in operations with each other. Errors related to these are known as type errors. Type checking is the process of verifying and enforcing the constraints of types. Compile time type checking also known as static type checking. Run time type checking is known as dynamic type checking. If a language specification requires its typing rules strongly (i.e., more or less allowing only those automatic type conversions which do not lose information), one can refer to the process as strongly typed, if not, as weakly typed.[http://en.wikipedia.org/wiki/Type_system]
The above classification can be represented as -

[[Image:Meta_2.jpg]]

== Statically Typed Programming Languages ==

Statically typed languages ensure that a fixed type is assigned by the programmer to every variable and parameter. Thus, every expression type can be deduced and type checked during compilation. Static languages try to fix most errors during compile time and strive to minimize failures during run time. Due to this there are many type constraints on the programmer while coding. At run time, the program uses the classes that it has been given and in this way statically typed languages make distinctions between what happens at compile time and what happens at run time. Examples of statically typed languages are C, C++, Java, C#.

== Dynamically Typed Programming Languages ==

In dynamically typed languages, the variables and parameters do not have a designated type and may take different values at different times. In all the operations, the operands must be type checked at runtime just before performing the operation. Dynamically typed languages don’t need to make a distinction between classes created at compile time and classes provided. It is possible to define classes at run time and in fact, classes are always defined at run time. These eliminate many developer constraints by avoiding the need of book keeping, declarations etc. Due to this flexibility these languages make an ideal candidate for prototyping and are widely used in agile development environments. However, dynamic languages are known to have performance issues. Static languages have code optimization features at compile time, but dynamic languages allow runtime code optimizations only. [http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages] In dynamically typed languages, the interpreter deduces type and type conversions, this makes development time faster, but it also can provoke runtime failures. These runtime failures are caught early on during compile time for statically typed languages.
Examples of dynamically typed languages include Perl, Python, JavaScript, PHP, Ruby, Groovy.

= Metaprogramming in statically typed languages =

In safety languages [syntactically verbose], metaprogramming is not a standard feature, it can however be achieved. Also, static typing in meta-programs has a number of advantages. In addition to guaranteeing that the meta-program encounters no type-errors while manipulating object-programs, a statically typed metaprogramming language can also guarantee that any of the object-programs generated by the meta-program are also type-correct. A disadvantage of these type system is that (in case of meta-programming languages with weaker type systems) they sometime may be too restrictive in object-programs that the programmer is allowed to construct.

== Techniques and Packages ==

Many language features can be leveraged to achieve some form of characteristics needed to achieve metaprogramming. For instance, languages that support reflection also allow for dynamic code generation. e.g. In Microsoft .NET Framework use of "System.Reflection.Emit" namespace is used to generate types and methods at runtime.

=== Reflection ===

Reflection is a valuable language feature to facilitate metaprogramming. Reflection is defined as the ability of a programming language to be its own meta-language. Thus, reflection is writing programs that manipulate other programs or themselves. [http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm] 
e.g. In Java, reflection enables to discover information about the loaded classes:
* Fields,
* Methods and constructors
* Generics information
* Metadata annotations
It also enables to use these metaobjects to their instances in run time environment.
E.g. Method.invoke(Object o, Object… args)
With the Java reflection API, you can interrogate an object to get all sorts of information about its class.

Consider the following simple example:
public class HelloWorld {
public void printName() {
System.out.println(this.getClass().getName());
}
}

The line
(new HelloWorld()).printName();
sends the string HelloWorld to standard out. Now let x be an instance of HelloWorld or one of its subclasses. The line
x.printName();
sends the string naming the class to standard out.

The printName method examines the object for its class (this.getClass()). In doing so, the decision of what to print is made by delegating to the object's class. The method acts on this decision by printing the returned name. Without being overridden, the printName method behaves differently for each subclass than it does for HelloWorld. The printName method is flexible; it adapts to the class that inherits it, causing the change in behavior.

=== Annotations ===

Annotations are a metaprogramming facility that allow the code to be marked with defined tags. Many APIs require a fair amount of boilerplate code. This boilerplate could be generated automatically by a tool if the program were “decorated” with annotations indicating which methods were remotely accessible. Metadata provided using annotations is beneficial for documentation, compiler checking, and code analysis. One can use this metadata to indicate if methods are dependent on other methods, if they are incomplete, if a certain class must reference another class, and so on. It is used by the compiler to perform some basic compile-time checking. For example there is a override annotation that lets you specify that a method overrides another method from a superclass. At this, the Java compiler will ensure that the behavior you indicate in your metadata actually happens at a code level as well.

An “annotation” has an “annotation type” associated with it which is used for defining it. It is used when you want to create a custom annotation. The type is the actual construct used, and the annotation is the specific usage of that type. An annotation type definition takes an "at" (@) sign, followed by the interface keyword plus the annotation name. On the other hand, an annotation takes the form of an "at" sign (@), followed by the annotation type [http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm].

Example to Define an Annotation (Annotation type)

public @interface MyAnnotation {
String doSomething();}
Example to Annotate Your Code (Annotation)
MyAnnotation (doSomething="What to do")
public void mymethod() {
....
}

==== Annotation Types ====
There are three annotation types:
* '''Marker:''' Marker type annotations have no elements, except the annotation name itself.
Example:
public @interface MyAnnotation {
}
Usage:
@MyAnnotation
public void mymethod() {
....
}

* '''Single-Element:''' Single-element, or single-value type, annotations provide a single piece of data only. This can be represented with a data=value pair or, simply with the value (a shortcut syntax) only, within parenthesis.
Example:

public @interface MyAnnotation
{
String doSomething();
}

Usage:
@MyAnnotation ("What to do")
public void mymethod() {
....
}

* '''Full-value or multi-value:''' Full-value type annotations have multiple data members. Therefore, you must use a full data=value parameter syntax for each member.
Example:
public @interface MyAnnotation {
String doSomething();
int count; String date();
}
Usage:
@MyAnnotation (doSomething="What to do", count=1,
date="09-09-2005")
public void mymethod() {

=== Generics ===

Generic programming is a style of computer programming in which algorithms are written in terms of to-be-specified-later types that are then instantiated when needed for specific types provided as parameters. [http://en.wikipedia.org/wiki/Generic_programming] Java Generics are primarily a way for library authors to write something once, which users can customize to their own types. They allow the creation of classes and methods that work in the same way on different types of objects. The term "generic" comes from the idea that we'd like to be able to write general algorithms that can be broadly reused for many types of objects rather than having to adapt our code to fit each circumstance.

Generics add a way to specify concrete types to general purpose classes and methods that operated on object before. A Java collection is a flexible data structure that can hold heterogeneous objects where the elements may have any reference type. When you take an element out of a collection, you must cast it to the type of element that is stored in the collection. Generics provides a way for you to communicate the type of a collection to the compiler, so that it can be checked. Once the compiler knows the element type of the collection, the compiler can check that the collection has been used consistently and can insert the correct casts on values being taken out of the collection.[5] Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parametrized types (which are technically known as raw types).

Consider a non-generic example:
//This program removes 4-letter words from c. Elements must be strings
static void expurgate(Collection c)
{
for (Iterator i = c.iterator(); i.hasNext(); )
if (((String) i.next()).length() == 4)
i.remove();
}
Here is the same example modified to use generics:
//This program removes the 4-letter words from c
static void expurgate(Collection<String> c)
{
for (Iterator<String> i = c.iterator(); i.hasNext(); )
if (i.next().length() == 4)
i.remove();
}
The declaration above reads as “Collection of String c.” Collection is a generic class that takes ‘String’ as its type parameter. The code using generics is clearer and safer. Unsafe cast and a number of extra parentheses have been eliminated. More importantly, we have moved part of the specification of the method from a comment to its signature, so the compiler can verify at compile time that the type constraints are not violated at run time.[http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf]

=== Template Metaprogramming ===
Template metaprogramming(TMP) or Static Metaprogramming is a technique that allows the execution of programs at compile-time. It uses extremely early binding.
A primary requirement for a metaprogramming language is providing high-level abstractions to hide the internal representation of base programs.[http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf] Each template language is specific for a base language and is generated from it. In this sense, a language of templates is a superset of the base language. Thus templates are abstractions that encapsulate a program pattern written by example. This concept has been explained in detail in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#C.2B.2B_Template_Metaprogramming section 3.2.5]

Uses of template metaprogramming:
* Compile-time dimensional analysis
* Multiple dispatch
* Design patterns
* Code optimization
* Lexing and parsing

== Packages ==

=== Javassist (Java Programming Assistant) ===

Javassist is a Java library providing means to manipulate the Java bytecode of an application. It provides the support for structural reflection, i.e. the ability to change the implementation of a class at runtime. [http://www.csg.is.titech.ac.jp/~chiba/javassist/] Javassist is explicit metaprogramming, in which the metalanguage is Java. It is a load-time reflective system for Java which enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it. Unlike other similar bytecode editors, Javassist provides two levels of API: source level and bytecode level.

If the users use the source-level API, they can edit a class file without knowledge of the specifications of the Java bytecode. They do not have to even write an inserted bytecode sequence; Javassist instead can compile a fragment of source text on line (for example, just a single statement). This ease of use is a unique feature of Javassit against other tools. One can even specify inserted bytecode in the form of source text and Javassist compiles it on the fly. On the other hand, the bytecode-level API allows the users to directly edit a class file as other editors. Thus it makes Java bytecode manipulation simple.

Javassist has the following applications:
* Aspect Oriented Programming: Javassist can be a good tool for introducing new methods into a class and for inserting before/after/around advice at the both caller and callee sides.
* Reflection: One of applications of Javassist is runtime reflection; Javassist enables Java programs to use a metaobject that controls method calls on base-level objects. No specialized compiler or virtual machine are needed.
* Remote method invocation: Another application is remote method invocation. Javassist enables applets to call a method on a remote object running on the web server. Unlike the Java RMI, the programmer does notneed a stub compiler such as rmic; the stub code is dynamically produced by Javassist.

Example:
BufferedInputStream fin = new BufferedInputStream(new FileInputStream("Point.class"));
ClassFile cf = new ClassFile(new DataInputStream(fin));

A ClassFile object can be written back to a class file. write() in ClassFile writes the contents of the class file to a given DataOutputStream. ClassFile provides addField() and addMethod() for adding a field or a method (note that a constructor is regarded as a method at the bytecode level). It also provides addAttribute() for adding an attribute to the class file.

To examine every bytecode instruction in a method body, CodeIterator is useful. A CodeIterator object allows you to visit every bytecode instruction one by one from the beginning to the end. To otbain this object, do as follows:

ClassFile cf = ... ;
MethodInfo minfo = cf.getMethod("move"); // we assume move is not overloaded.
CodeAttribute ca = minfo.getCodeAttribute();
CodeIterator i = ca.iterator();

Other extensions are being developed to include reflective systems for C++ and Java e.g. OpenC++ and OpenJava which are extensible preprocessors based on compile-time reflection in C++ and Java respectively.

=== JRuby ===

JRuby is a complete implementation of Ruby in Java. The scripting and functional features of the Ruby language can be used by Java developers.[http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules] Simple metaprogramming techniques can be extended from Ruby so that Java packages are mapped onto to Ruby modules. This would be something like a Ruby-Java Bridge, since JRuby can be run from any platform with a JVM.

Example:
Using JRuby API calling JRuby from Java

import org.jruby.*;
public class SimpleJRubyCall {
public static void main(String[] args) {
Ruby runtime = Ruby.getDefaultInstance();
runtime.evalScript(“puts 1+2”);
}
}

With metaprogramming using JRuby one can
* add methods to class,
* add instance methods
* add to have Java classes

Since metaprogramming empowers the programmer to create domain specific languages(DSL), the ones created by JRuby can always leverage Java libraries to build wrapper functionalities.
e.g. Simple JRuby DSL on top of HtmlUnit

=== AspectJ ===
Another library worth mentioning here is AspectJ. It enforces the aspect oriented programming (AOP) approach in Java. Aspect oriented programming is a complimentary programming paradigm to object oriented programming and is used to improve the modularity of software systems. Thus, while object oriented programming is great for modeling common behavior on a hierarchy of objects, aspect oriented programming allows you to define cross-cutting concerns by adding direct semantics and can be applied across heterogeneous object models. [http://static.springsource.org/spring/docs/2.0.x/reference/aop.html] Applications of aspect oriented programming include logging, instrumenting and debugging.

In object oriented programs, the natural unit of modularity is the class. In AspectJ, aspects modularize concerns that affect more than one class. In addition to classes, aspect oriented programming uses 'aspects'. Aspects enable modularization of crosscutting concerns such as transaction management that cut across multiple types and objects. Thus, AspectJ package achieves metaprogramming features with more controllability.

AspectJ introduces declaring aspects in the statically typed language Java by using 3 key concepts -
* Join Points - well defined points in program execution
* Advice - defines additional code to be executed around join points
* Pointcut - define those points in the source code of a program where an advice will be applied

The core task of AspectJ's advice weaver is to statically transform a program so that at runtime it will behave according to the AspectJ language semantics. The AspectJ weaver takes class files as input and produces class files as output. The weaving process itself can take place at one of three different times: compile-time, post-compile time, and load-time. These two java files are 'woven' together by compiler i.e. the class and the aspect behavior are tied together. This is also known as 'plugging-in' the aspect. [http://oreilly.com/catalog/9780596006549]

Example - Simple tracing/logging

Consider the HelloWorld class below which implements an application that simply displays "Hello World!" on the standard output.
package helloworld;
class HelloWorld {
public static void main(String[] args) {
new HelloWorld().printMessage();
}
void printMessage() {
System.out.println("Hello world!");
}
}

Consider another Java source file with an aspect definition as follows -
package helloworld;
aspect Trace of eachobject(instanceof(HelloWorld)) {
pointcut printouts(): receptions(void printMessage());
before(): printouts() {
System.out.println("*** Entering printMessage ***");
}
after(): printouts() {
System.out.println("*** Exiting printMessage ***");
}
}

In above example, the Trace aspect injects tracing messages before and after method main of class HelloWorld. If one does not want tracing, one can simply leave the aspect out and plug it in as and when required.

In contrast to reflection[low level], AspectJ provides more carefully controlled power, drawing on the rules learned from object-oriented development to encourage a clean and understandable program structure. An aspect imposes behavior on a class, rather than a class requesting behavior from an aspect. An aspect can modify a class without needing to edit that class - also known as 'reverse inheritance'.

=== MetaJ ===

MetaJ is another package that supports metaprogramming in the Java language. A MetaJ program consists of the Java code with special metaprogramming declarations that will control how the output code is created. It uses templates and reflection. Templates are abstractions that encapsulate a program pattern written by example. Templates are translated to Java classes, so they can be accessed in the metaprogram. Accessing patterns by example inside ordinary Java programs is a major feature of MetaJ programming. [http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment]

Language Dependency:
MetaJ comprises of a set of concepts that are independent of the base language. These are syntax trees, code references, code iterators and code templates. A framework is defined which in which features common to most languages are abstracted. This supports independence from base language. Thus, generic operations can be defined and components that are language dependent can be plugged onto it.

Execution Flow Representation:

[[Image:Meta_3.jpg]]

Example:

Template : SampleTempl

package myTempl;
language = Java // base language plugin
template #CompilationUnit SampleTempl{
#[#PackageDeclaration:pck]#
#[#ImportDeclarationList:imps]#
class SampleTempl { ... }
#TypeDeclaration:td
}

Instance of Template : Java Code

package myTempl;
import metaj.framework.AbstractTemplate;
public class SampleTempl extends AbstractTemplate{
public final Reference imps, td, pck;
... // Implementation of superclass abstract methods
}

Java SDK7 has added support for dynamic typing and metaprogramming and includes MetaJ implementation.

=== C++ Template Metaprogramming ===

In C++, [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#Template_Metaprogramming static metaprogramming] is implemented with the help of reflection. The most important implementation of reflection in C++ is using the feature of run time type-identification (RTTI) [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules]. RTTI is a system that keeps information about an object's data type in memory at run time. Run-time type information can apply to simple data types, such as integers and characters, or to generic objects. Enabling RTTI in C++ allows the use of dynamic_cast<> operation, the typeid operator or exceptions [http://en.wikipedia.org/wiki/Run-time_type_information].

The template mechanism in C++ allows defining parametrized classes and functions. Templates together with other C++ features constitute a Turing-complete, compile-time sub- language of C++. A Turing-complete language is a language with at least a conditional and a looping construct. C++ can be considered to be a two-level language since a C++ program may contain both static code, which is evaluated at compile time, and dynamic code, which is executed at run time. Template meta-programs are the part of a C++ source that is executed during compilation. A meta-program can access information about types not generally available to ordinary programs [http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf].

Given below is an example of how to use templates for writing a common recursive factorial program:
template<int count>
class FACTOR{
public:
enum {RESULT = count * FACTOR<count-1>::RESULT};
};
class FACTOR<1>{
public:
enum {RESULT = 1};
};

If we write this-
int j = FACTOR<5>::RESULT;

The above line will calculate the value of 5 factorial. As we instantiate FACTOR<5> the definition of this class depends on FACTOR<4>, which in turn depend on FACTOR<3> and so on. The compiler needs to create all these classes until the template specialization FACTOR<1> is reached. This means the entire recursion is done by the compiler during compile time and it uses the result as if it is a constant.

= Conclusion =

Dynamically typed languages are best suited to provide support for metaprogramming due to their inherent nature of easily overcoming distinction between code and data e.g. Lisp provides this feature of interchangeability. Code and data are both represented in Lisp as lists, so any list can easily be treated as either code or data.
It’s simple, therefore, to manipulate code as data, and then execute it – either via EVAL or by returning it as the result of a macro expansion. [3]

Thus, statically typed languages achieve metaprogramming using various techniques and tools to achieve the level of flexibility that dynamic languages provide immanently.

= References and Notes =

*[1] [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming]
*[2] [http://en.wikipedia.org/wiki/Type_system Type System]
*[3] http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages
*[4] http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm
*[5] http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm
*[6] http://en.wikipedia.org/wiki/Generic_programming
*[7] http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf
*[8] http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf
*[9] http://www.csg.is.titech.ac.jp/~chiba/javassist/
*[10] http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules
*[11] http://static.springsource.org/spring/docs/2.0.x/reference/aop.html
*[12] http://oreilly.com/catalog/9780596006549
*[13] http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment
*[14] http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules
*[15] http://en.wikipedia.org/wiki/Run-time_type_information
*[16] http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf

= Further Reading =

*[http://www.cs.tut.fi/~kk/webstuff/MetaprogrammingCpp.pdf Metaprogramming in C++]
*[http://en.wikipedia.org/wiki/Automatic_programming Automatic/Generative Programming]
*[http://www.slideshare.net/dogangoko/new-features-of-java7-se-presentation News in the upcoming Java 7]

CSC/ECE 517 Fall 2010/ch2 S24 rm

2010-09-29T16:17:12Z

Whiteopal: /* Conclusion */

'''Metaprogramming in Statically Typed Languages'''

''"I'd rather write programs that write programs than write programs" - Richard Sites''

__TOC__

= Introduction =

Metaprogramming is an inherent feature of dynamically typed languages [e.g. Ruby]. However, achieving metaprogramming in statically typed languages [e.g. Java] becomes complex due to compile time abstraction verification. In this topic, we explore how tools and packages are usedto implement metaprogramming in statically typed languages .

== Metaprogramming ==

Metaprogramming is a programming technique of writing computer programs that write or manipulate other programs or themselves, as data. [http://en.wikipedia.org/wiki/Metaprogramming] In other words, it is a programming technique of writing programs with a higher level of abstraction to make it appear as generative programming.

Metaprogramming involves two kinds of languages-
* '''Meta-language''' is the language in which meta-programs, which construct or manipulate other programs, are written.
* '''Object-language''' is the language of programs being manipulated.
This makes them ‘meta level programs’ whose problem domain are other ‘base level programs’.

[[Image:Meta_1.jpg]]

The ability of a programming language to be its own metalanguage is called reflection or reflexivity.

Simple example of a metaprogram:
 Let us consider a totally fabricated example for our understanding at very high level. Suppose we need to write a C program that printed the following 500 lines of text with a restriction that the program could not use any kind of loop or goto instruction.

Output expected:

1 Mississippi
2 Mississippi
3 Mississippi
4 Mississippi
...
499 Mississippi
500 Mississippi

In C this would be then coded as:

#include <stdio.h>
int main(void) {
printf("1 Mississippi\n");
printf("2 Mississippi\n");
-
-
-
printf("499 Mississippi\n");
printf("500 Mississippi\n");
return 0;
}

With the power of a metaprogramming language we can write another program that writes this program automatically.

Ruby code:

File.open('mississippi.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(500) do |i|
output.puts " printf(\"#{i} " +
"Mississippi\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called mississippi.c with the expected 500+ lines of C source code.Here, mississippi.c is the generated code and ruby code is the metaprogram.

== Applications of Metaprogramming ==

Metaprogramming is an attractive technique needed when one needs to alter the behavior of a program at run time. Due to its generative nature, it has numerous applications in program development. It can achieve program development without rewriting boiler-plate code [http://en.wikipedia.org/wiki/Boilerplate_text] all the time, ensuring efficiency, increasing modularity and minimizing inconsistent implementation errors. Program generators and program analyzers are the two main categories of meta programs. Metaprograms can be compilers, interpreters, type checkers etc. Some commonly used applications include using a program that outputs source code to -
* generate sine/cosine/whatever lookup tables
* to extract a source-form representation of a binary file
* to compile your bitmaps into fast display routines
* to extract documentation, initialization/finalization code, description tables, as well as normal code from the same source files
* to have customized assembly code, generated from a perl/shell/scheme script that does arbitrary processing
* to propagate data defined at one point only into several cross-referencing tables and code chunks.

Programmers can focus more on the main business logic and new features to be implemented rather than writing repetitive chunks of code (e.g. setups, stubs)[1].

= Typing in Programming Languages =

Earlier programming languages [e.g. Assembly] were written such that each machine level function was reflected in the program code. With advancement in programming languages a certain level of abstraction was reached wherein lower level details were abstracted with one functional unit of work and represented by fewer lines of code e.g. primitive variables are represented with higher level abstract classes. With this abstraction arose a need for checking the validity of operations that could be performed with these abstractions in place.

Typing in programming languages is property of operations and variables in the language that ensure that certain kinds of values that are invalid are not used in operations with each other. Errors related to these are known as type errors. Type checking is the process of verifying and enforcing the constraints of types. Compile time type checking also known as static type checking. Run time type checking is known as dynamic type checking. If a language specification requires its typing rules strongly (i.e., more or less allowing only those automatic type conversions which do not lose information), one can refer to the process as strongly typed, if not, as weakly typed.[http://en.wikipedia.org/wiki/Type_system]
The above classification can be represented as -

[[Image:Meta_2.jpg]]

== Statically Typed Programming Languages ==

Statically typed languages ensure that a fixed type is assigned by the programmer to every variable and parameter. Thus, every expression type can be deduced and type checked during compilation. Static languages try to fix most errors during compile time and strive to minimize failures during run time. Due to this there are many type constraints on the programmer while coding. At run time, the program uses the classes that it has been given and in this way statically typed languages make distinctions between what happens at compile time and what happens at run time. Examples of statically typed languages are C, C++, Java, C#.

== Dynamically Typed Programming Languages ==

In dynamically typed languages, the variables and parameters do not have a designated type and may take different values at different times. In all the operations, the operands must be type checked at runtime just before performing the operation. Dynamically typed languages don’t need to make a distinction between classes created at compile time and classes provided. It is possible to define classes at run time and in fact, classes are always defined at run time. These eliminate many developer constraints by avoiding the need of book keeping, declarations etc. Due to this flexibility these languages make an ideal candidate for prototyping and are widely used in agile development environments. However, dynamic languages are known to have performance issues. Static languages have code optimization features at compile time, but dynamic languages allow runtime code optimizations only. [http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages] In dynamically typed languages, the interpreter deduces type and type conversions, this makes development time faster, but it also can provoke runtime failures. These runtime failures are caught early on during compile time for statically typed languages.
Examples of dynamically typed languages include Perl, Python, JavaScript, PHP, Ruby, Groovy.

= Metaprogramming in statically typed languages =

In safety languages [syntactically verbose], metaprogramming is not a standard feature, it can however be achieved. Also, static typing in meta-programs has a number of advantages. In addition to guaranteeing that the meta-program encounters no type-errors while manipulating object-programs, a statically typed metaprogramming language can also guarantee that any of the object-programs generated by the meta-program are also type-correct. A disadvantage of these type system is that (in case of meta-programming languages with weaker type systems) they sometime may be too restrictive in object-programs that the programmer is allowed to construct.

== Techniques and Packages ==

Many language features can be leveraged to achieve some form of characteristics needed to achieve metaprogramming. For instance, languages that support reflection also allow for dynamic code generation. e.g. In Microsoft .NET Framework use of "System.Reflection.Emit" namespace is used to generate types and methods at runtime.

=== Reflection ===

Reflection is a valuable language feature to facilitate metaprogramming. Reflection is defined as the ability of a programming language to be its own meta-language. Thus, reflection is writing programs that manipulate other programs or themselves. [http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm] 
e.g. In Java, reflection enables to discover information about the loaded classes:
* Fields,
* Methods and constructors
* Generics information
* Metadata annotations
It also enables to use these metaobjects to their instances in run time environment.
E.g. Method.invoke(Object o, Object… args)
With the Java reflection API, you can interrogate an object to get all sorts of information about its class.

Consider the following simple example:
public class HelloWorld {
public void printName() {
System.out.println(this.getClass().getName());
}
}

The line
(new HelloWorld()).printName();
sends the string HelloWorld to standard out. Now let x be an instance of HelloWorld or one of its subclasses. The line
x.printName();
sends the string naming the class to standard out.

The printName method examines the object for its class (this.getClass()). In doing so, the decision of what to print is made by delegating to the object's class. The method acts on this decision by printing the returned name. Without being overridden, the printName method behaves differently for each subclass than it does for HelloWorld. The printName method is flexible; it adapts to the class that inherits it, causing the change in behavior.

=== Annotations ===

Annotations are a metaprogramming facility that allow the code to be marked with defined tags. Many APIs require a fair amount of boilerplate code. This boilerplate could be generated automatically by a tool if the program were “decorated” with annotations indicating which methods were remotely accessible. Metadata provided using annotations is beneficial for documentation, compiler checking, and code analysis. One can use this metadata to indicate if methods are dependent on other methods, if they are incomplete, if a certain class must reference another class, and so on. It is used by the compiler to perform some basic compile-time checking. For example there is a override annotation that lets you specify that a method overrides another method from a superclass. At this, the Java compiler will ensure that the behavior you indicate in your metadata actually happens at a code level as well.

An “annotation” has an “annotation type” associated with it which is used for defining it. It is used when you want to create a custom annotation. The type is the actual construct used, and the annotation is the specific usage of that type. An annotation type definition takes an "at" (@) sign, followed by the interface keyword plus the annotation name. On the other hand, an annotation takes the form of an "at" sign (@), followed by the annotation type [http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm].

Example to Define an Annotation (Annotation type)

public @interface MyAnnotation {
String doSomething();}
Example to Annotate Your Code (Annotation)
MyAnnotation (doSomething="What to do")
public void mymethod() {
....
}

==== Annotation Types ====
There are three annotation types:
* '''Marker:''' Marker type annotations have no elements, except the annotation name itself.
Example:
public @interface MyAnnotation {
}
Usage:
@MyAnnotation
public void mymethod() {
....
}

* '''Single-Element:''' Single-element, or single-value type, annotations provide a single piece of data only. This can be represented with a data=value pair or, simply with the value (a shortcut syntax) only, within parenthesis.
Example:

public @interface MyAnnotation
{
String doSomething();
}

Usage:
@MyAnnotation ("What to do")
public void mymethod() {
....
}

* '''Full-value or multi-value:''' Full-value type annotations have multiple data members. Therefore, you must use a full data=value parameter syntax for each member.
Example:
public @interface MyAnnotation {
String doSomething();
int count; String date();
}
Usage:
@MyAnnotation (doSomething="What to do", count=1,
date="09-09-2005")
public void mymethod() {

=== Generics ===

Generic programming is a style of computer programming in which algorithms are written in terms of to-be-specified-later types that are then instantiated when needed for specific types provided as parameters. [http://en.wikipedia.org/wiki/Generic_programming] Java Generics are primarily a way for library authors to write something once, which users can customize to their own types. They allow the creation of classes and methods that work in the same way on different types of objects. The term "generic" comes from the idea that we'd like to be able to write general algorithms that can be broadly reused for many types of objects rather than having to adapt our code to fit each circumstance.

Generics add a way to specify concrete types to general purpose classes and methods that operated on object before. A Java collection is a flexible data structure that can hold heterogeneous objects where the elements may have any reference type. When you take an element out of a collection, you must cast it to the type of element that is stored in the collection. Generics provides a way for you to communicate the type of a collection to the compiler, so that it can be checked. Once the compiler knows the element type of the collection, the compiler can check that the collection has been used consistently and can insert the correct casts on values being taken out of the collection.[5] Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parametrized types (which are technically known as raw types).

Consider a non-generic example:
//This program removes 4-letter words from c. Elements must be strings
static void expurgate(Collection c)
{
for (Iterator i = c.iterator(); i.hasNext(); )
if (((String) i.next()).length() == 4)
i.remove();
}
Here is the same example modified to use generics:
//This program removes the 4-letter words from c
static void expurgate(Collection<String> c)
{
for (Iterator<String> i = c.iterator(); i.hasNext(); )
if (i.next().length() == 4)
i.remove();
}
The declaration above reads as “Collection of String c.” Collection is a generic class that takes ‘String’ as its type parameter. The code using generics is clearer and safer. Unsafe cast and a number of extra parentheses have been eliminated. More importantly, we have moved part of the specification of the method from a comment to its signature, so the compiler can verify at compile time that the type constraints are not violated at run time.[http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf]

=== Template Metaprogramming ===
Template metaprogramming(TMP) or Static Metaprogramming is a technique that allows the execution of programs at compile-time. It uses extremely early binding.
A primary requirement for a metaprogramming language is providing high-level abstractions to hide the internal representation of base programs.[http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf] Each template language is specific for a base language and is generated from it. In this sense, a language of templates is a superset of the base language. Thus templates are abstractions that encapsulate a program pattern written by example. This concept has been explained in detail in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#C.2B.2B_Template_Metaprogramming section 3.2.5]

Uses of template metaprogramming:
* Compile-time dimensional analysis
* Multiple dispatch
* Design patterns
* Code optimization
* Lexing and parsing

== Packages ==

=== Javassist (Java Programming Assistant) ===

Javassist is a Java library providing means to manipulate the Java bytecode of an application. It provides the support for structural reflection, i.e. the ability to change the implementation of a class at runtime. [http://www.csg.is.titech.ac.jp/~chiba/javassist/] Javassist is explicit metaprogramming, in which the metalanguage is Java. It is a load-time reflective system for Java which enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it. Unlike other similar bytecode editors, Javassist provides two levels of API: source level and bytecode level.

If the users use the source-level API, they can edit a class file without knowledge of the specifications of the Java bytecode. They do not have to even write an inserted bytecode sequence; Javassist instead can compile a fragment of source text on line (for example, just a single statement). This ease of use is a unique feature of Javassit against other tools. One can even specify inserted bytecode in the form of source text and Javassist compiles it on the fly. On the other hand, the bytecode-level API allows the users to directly edit a class file as other editors. Thus it makes Java bytecode manipulation simple.

Javassist has the following applications:
* Aspect Oriented Programming: Javassist can be a good tool for introducing new methods into a class and for inserting before/after/around advice at the both caller and callee sides.
* Reflection: One of applications of Javassist is runtime reflection; Javassist enables Java programs to use a metaobject that controls method calls on base-level objects. No specialized compiler or virtual machine are needed.
* Remote method invocation: Another application is remote method invocation. Javassist enables applets to call a method on a remote object running on the web server. Unlike the Java RMI, the programmer does notneed a stub compiler such as rmic; the stub code is dynamically produced by Javassist.

Example:
BufferedInputStream fin = new BufferedInputStream(new FileInputStream("Point.class"));
ClassFile cf = new ClassFile(new DataInputStream(fin));

A ClassFile object can be written back to a class file. write() in ClassFile writes the contents of the class file to a given DataOutputStream. ClassFile provides addField() and addMethod() for adding a field or a method (note that a constructor is regarded as a method at the bytecode level). It also provides addAttribute() for adding an attribute to the class file.

To examine every bytecode instruction in a method body, CodeIterator is useful. A CodeIterator object allows you to visit every bytecode instruction one by one from the beginning to the end. To otbain this object, do as follows:

ClassFile cf = ... ;
MethodInfo minfo = cf.getMethod("move"); // we assume move is not overloaded.
CodeAttribute ca = minfo.getCodeAttribute();
CodeIterator i = ca.iterator();

Other extensions are being developed to include reflective systems for C++ and Java e.g. OpenC++ and OpenJava which are extensible preprocessors based on compile-time reflection in C++ and Java respectively.

=== JRuby ===

JRuby is a complete implementation of Ruby in Java. The scripting and functional features of the Ruby language can be used by Java developers.[http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules] Simple metaprogramming techniques can be extended from Ruby so that Java packages are mapped onto to Ruby modules. This would be something like a Ruby-Java Bridge, since JRuby can be run from any platform with a JVM.

Example:
Using JRuby API calling JRuby from Java

import org.jruby.*;
public class SimpleJRubyCall {
public static void main(String[] args) {
Ruby runtime = Ruby.getDefaultInstance();
runtime.evalScript(“puts 1+2”);
}
}

With metaprogramming using JRuby one can
* add methods to class,
* add instance methods
* add to have Java classes

Since metaprogramming empowers the programmer to create domain specific languages(DSL), the ones created by JRuby can always leverage Java libraries to build wrapper functionalities.
e.g. Simple JRuby DSL on top of HtmlUnit

=== AspectJ ===
Another library worth mentioning here is AspectJ. It enforces the aspect oriented programming (AOP) approach in Java. Aspect oriented programming is a complimentary programming paradigm to object oriented programming and is used to improve the modularity of software systems. Thus, while object oriented programming is great for modeling common behavior on a hierarchy of objects, aspect oriented programming allows you to define cross-cutting concerns by adding direct semantics and can be applied across heterogeneous object models. [http://static.springsource.org/spring/docs/2.0.x/reference/aop.html] Applications of aspect oriented programming include logging, instrumenting and debugging.

In object oriented programs, the natural unit of modularity is the class. In AspectJ, aspects modularize concerns that affect more than one class. In addition to classes, aspect oriented programming uses 'aspects'. Aspects enable modularization of crosscutting concerns such as transaction management that cut across multiple types and objects. Thus, AspectJ package achieves metaprogramming features with more controllability.

AspectJ introduces declaring aspects in the statically typed language Java by using 3 key concepts -
* Join Points - well defined points in program execution
* Advice - defines additional code to be executed around join points
* Pointcut - define those points in the source code of a program where an advice will be applied

The core task of AspectJ's advice weaver is to statically transform a program so that at runtime it will behave according to the AspectJ language semantics. The AspectJ weaver takes class files as input and produces class files as output. The weaving process itself can take place at one of three different times: compile-time, post-compile time, and load-time. These two java files are 'woven' together by compiler i.e. the class and the aspect behavior are tied together. This is also known as 'plugging-in' the aspect. [http://oreilly.com/catalog/9780596006549]

Example - Simple tracing/logging

Consider the HelloWorld class below which implements an application that simply displays "Hello World!" on the standard output.
package helloworld;
class HelloWorld {
public static void main(String[] args) {
new HelloWorld().printMessage();
}
void printMessage() {
System.out.println("Hello world!");
}
}

Consider another Java source file with an aspect definition as follows -
package helloworld;
aspect Trace of eachobject(instanceof(HelloWorld)) {
pointcut printouts(): receptions(void printMessage());
before(): printouts() {
System.out.println("*** Entering printMessage ***");
}
after(): printouts() {
System.out.println("*** Exiting printMessage ***");
}
}

In above example, the Trace aspect injects tracing messages before and after method main of class HelloWorld. If one does not want tracing, one can simply leave the aspect out and plug it in as and when required.

In contrast to reflection[low level], AspectJ provides more carefully controlled power, drawing on the rules learned from object-oriented development to encourage a clean and understandable program structure. An aspect imposes behavior on a class, rather than a class requesting behavior from an aspect. An aspect can modify a class without needing to edit that class - also known as 'reverse inheritance'.

=== MetaJ ===

MetaJ is another package that supports metaprogramming in the Java language. A MetaJ program consists of the Java code with special metaprogramming declarations that will control how the output code is created. It uses templates and reflection. Templates are abstractions that encapsulate a program pattern written by example. Templates are translated to Java classes, so they can be accessed in the metaprogram. Accessing patterns by example inside ordinary Java programs is a major feature of MetaJ programming. [http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment]

Language Dependency:
MetaJ comprises of a set of concepts that are independent of the base language. These are syntax trees, code references, code iterators and code templates. A framework is defined which in which features common to most languages are abstracted. This supports independence from base language. Thus, generic operations can be defined and components that are language dependent can be plugged onto it.

Execution Flow Representation:

[[Image:Meta_3.jpg]]

Example:

Template : SampleTempl

package myTempl;
language = Java // base language plugin
template #CompilationUnit SampleTempl{
#[#PackageDeclaration:pck]#
#[#ImportDeclarationList:imps]#
class SampleTempl { ... }
#TypeDeclaration:td
}

Instance of Template : Java Code

package myTempl;
import metaj.framework.AbstractTemplate;
public class SampleTempl extends AbstractTemplate{
public final Reference imps, td, pck;
... // Implementation of superclass abstract methods
}

Java SDK7 has added support for dynamic typing and metaprogramming and includes MetaJ implementation.

=== C++ Template Metaprogramming ===

In C++, [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24_rm#Template_Metaprogramming static metaprogramming] is implemented with the help of reflection. The most important implementation of reflection in C++ is using the feature of run time type-identification (RTTI) [http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules]. RTTI is a system that keeps information about an object's data type in memory at run time. Run-time type information can apply to simple data types, such as integers and characters, or to generic objects. Enabling RTTI in C++ allows the use of dynamic_cast<> operation, the typeid operator or exceptions [http://en.wikipedia.org/wiki/Run-time_type_information].

The template mechanism in C++ allows defining parametrized classes and functions. Templates together with other C++ features constitute a Turing-complete, compile-time sub- language of C++. A Turing-complete language is a language with at least a conditional and a looping construct. C++ can be considered to be a two-level language since a C++ program may contain both static code, which is evaluated at compile time, and dynamic code, which is executed at run time. Template meta-programs are the part of a C++ source that is executed during compilation. A meta-program can access information about types not generally available to ordinary programs [http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf].

Given below is an example of how to use templates for writing a common recursive factorial program:
template<int count>
class FACTOR{
public:
enum {RESULT = count * FACTOR<count-1>::RESULT};
};
class FACTOR<1>{
public:
enum {RESULT = 1};
};

If we write this-
int j = FACTOR<5>::RESULT;

The above line will calculate the value of 5 factorial. As we instantiate FACTOR<5> the definition of this class depends on FACTOR<4>, which in turn depend on FACTOR<3> and so on. The compiler needs to create all these classes until the template specialization FACTOR<1> is reached. This means the entire recursion is done by the compiler during compile time and it uses the result as if it is a constant.

= Conclusion =

Dynamically typed languages are best suited to provide support for metaprogramming due to their inherent nature of easily overcoming distinction between code and data e.g. Lisp provides this feature of interchangeability. Code and data are both represented in Lisp as lists, so any list can easily be treated as either code or data.
It’s simple, therefore, to manipulate code as data, and then execute it – either via EVAL or by returning it as the result of a macro expansion. [3]

Thus, statically typed languages achieve metaprogramming using various techniques and tools to achieve the level of flexibility that dynamic languages provide immanently.

= References and Notes =

*[1] http://en.wikipedia.org/wiki/Metaprogramming
*[2] http://en.wikipedia.org/wiki/Type_system
*[3] http://www.slideshare.net/aminbandeali/dynamically-and-statically-typed-languages
*[4] http://www.developer.com/java/web/article.php/3504271/Java-Reflection-in-Action.htm
*[5] http://www.developer.com/java/other/article.php/3556176/An-Introduction-to-Java-Annotations.htm
*[6] http://en.wikipedia.org/wiki/Generic_programming
*[7] http://www.cs.tut.fi/~kk/webstuff/MetaProgrammingJavaKalvot.pdf
*[8] http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf
*[9] http://www.csg.is.titech.ac.jp/~chiba/javassist/
*[10] http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules
*[11] http://static.springsource.org/spring/docs/2.0.x/reference/aop.html
*[12] http://oreilly.com/catalog/9780596006549
*[13] http://www.jucs.org/jucs_10_7/metaj_an_extensible_environment
*[14] http://depth-first.com/articles/2006/10/24/metaprogramming-with-ruby-mapping-java-packages-onto-ruby-modules
*[15] http://en.wikipedia.org/wiki/Run-time_type_information
*[16] http://lcgapp.cern.ch/project/architecture/ReflectionPaper.pdf

= Further Reading =

*[http://www.cs.tut.fi/~kk/webstuff/MetaprogrammingCpp.pdf Metaprogramming in C++]
*[http://en.wikipedia.org/wiki/Automatic_programming Automatic/Generative Programming]
*[http://www.slideshare.net/dogangoko/new-features-of-java7-se-presentation News in the upcoming Java 7]