别跟我扯依赖注入

依赖注入（Dependencyinjection）在Java的流行框架中得到了广泛的应用，比如Struts，Spring等等。（Martin Fowler写过一篇这个模式的精彩文章，感兴趣的童鞋可以去度娘）在Fowler最先提出依赖注入这个术语之前，人们经常用“控制反转”（inversion ofcontrol）这个词来描述同样的事情。其实IOC的范围比依赖注入的范围更大，IOC包括依赖注入和依赖查找，本文主要介绍依赖注入。

首先看一个情形，有两个类我们姑且叫他们为A类和B类，并且A类依赖于B类，也就是说A类中需要调用B类中资源（方法或者属性）。大致的代码如下

public class A{
	public void importantMethod(){
		B b=....//获得一个B的实例
		b.usefulMethod();
		...
	}
	...
}

A类必须先获得B类的一个实例才可以使用B。也就是说在A中实例化B是肯定的，但是这样就加大了A与B的耦合，同时大大的削弱了A类的重用性。

再来看一个更实际的例子。下面给出的PersistenceManager类可以用来把对象存入一个数据库

public class PersistenceManager{
	public void store(Object object){
		DataSource dataSource=...//获得数据源
		try{
			Connection connection=dataSource.getConnection();
			...//将数据存入数据库
		}catch{
			
		}
	}
}

PersistenceManager依赖于DataSource。它必须先获得一个DataSource才能创建一个Connection对象来把数据插入到数据库中。在一个JavaEE应用程序里，获得一个数据源的常用方法是使用JNDI查询

DataSource dataSource=null;
try{
	context=new InitialContext();
	dataSource=(DataSource)context.lookup("java:/comp/env/jdbc/myDataSource");
}catch{

}

用于JDNI名是变化的，所以PersistenceManager的可重用性就大大降低。所谓“依赖注入”是指把以来关系“注入”到所依赖的类中。具体到PersistenceManager例子，我们应该把一个DataSource对象传递给PersistenceManager，而不是强迫PersistenceManager去创建一个。具体代码如下

public class PersistenceManager{
	private DataSource dataSource;
	public PersistenceManager(DataSource dataSource){
		this.dataSource=dataSource;
	}

	public void store(Objece object){
		try{
			Connection connection=dataSource.getConnection();
			...//将数据存入数据库
		}catch(SQLException e){
			
		}
	}
}

现在，不管是谁想用PersistenceManager，都必须通过PersistenceManager类的构造器“注入”一个DataSource的实例。现在的PersistenceManager与它将使用的DataSource实例之间的耦合就大大降低了。

通过构造器来注入依赖关系是注入方式的一种，依赖关系还可以通过一个setter方法来注入。回到刚才的PersistenceManager例子，我们也可以提供一种如下所示的方式：

public void setDataSource(DataSource dataSource){
	this.dataSource=dataSource;
}

以上就是 “依赖注入”的核心思想以及代码示例，总之还是那句老话高内聚，低耦合。该做什么做什么不该自己做的事不要做（让别人做好了传递给自己），否则自己责任就太大了，最终得不到高效的复用。