Java Spring MVC入门（五）——依赖注入之理论

Java Spring MVC入门（五）依赖注入之理论

为何需要依赖注入？

　　假设现在我们有这样的场景，A类要实现发邮件功能，那么代码可能会这样写：

class A
{
Mail myMail;

public void AMethod()//一个方法
{
myMail = new Mail();
　　　　 myMail.sendMail();
}
}

上面代码中，class A 内的AMethod方法体内直接new Mail() 创建对象，这样的写法是有问题的，假如此时由于业务需要，Mail类的构造函数发生了改变，创建对象的时候必须传参数“sendEmail” ，此时，项目中所有所有 new Mail() 都必须改为 new Mail(sendEmail) ：

class A{
Mail myMail;

public void AMethod()//一个方法
{
　　　　 String sendEmail = "lisan@163.com";
myMail = new Mail(sendEmail);
myMail.sendMail();
}
}

如果是小型项目那还好说，如果是大型项目，项目中可能有几千几万个地方都用到了"new Mail()"，我们都要一一修改，那么将是一场噩梦。像上面的情况我们称为：Class A 对 Class Mail 产生了依赖，也可以说他们之间有强耦合。

　　为了解决上面的问题，我们改一改写法（工厂模式）：

class A{

public void AMethod()//一个方法
{
MailFactory mailFactory = new MailFactory();
Mail myMail = mailFactory.getEmail();
myMail.sendMail();
}
}

class MailFactory{

public Mail getEmail(){
return new Mail();
//String sendEmail = "lisan@163.com";
//return new Mail(sendEmail);
}
}

从上面的代码我们可以看出，我们不直接在A里面去创建Mail对象，而是在MailFactory类里的getEmail方法里去创建，A方法体内去调用这个方法获得对象。如果Mail类的构造函数有所变动，我们只要改MailFactory的getMail方法这一个地方即可，这样看起来比上一种写法强多了。但是这样的写法也不是完全没有问题的，假如此时MailFactory的getMail方法要加一个参数（当然这种情况不多见），那么Class
A 里为了要加参数，还是要改代码。耦合依然存在。

根据上面两种写法我们可以看出，当某个Java对象（调用者），需要调用另外一个Java对象（被依赖对象）方法时，在传统模式下有两种做法：

　　1、原始做法

　　　　调用者主动创建被依赖对象，然后再调用被依赖方法

2、简单工厂模式

　　　　调用者先找到被依赖对象的工厂，然后通过主动通过工厂去获得被依赖对象，最后再调用被依赖方法。

第一种方法会导致调用者和被依赖对象类的强耦合，非常不利于代码维护和升级。

第二种方法解决了第一种方法的问题，不会产生强耦合，但是由于去主动通过工厂去获取被依赖对象，这就会带来调用组件与被依赖对象工厂的耦合。

为了彻底解决耦合问题，引入依赖注入（控制反转）设计模式。

依赖注入（控制反转）

由上面可以看出，第一和第二种方法都是主动获取被依赖对象，或多或少的会有一些耦合，那么如果调用者不去主动调用被依赖对象呢？改主动调用为被动接收呢？

依赖注入的本质就是改主动为被动，由主动调用请求改为被动接收。

　 在Java Spring中，被依赖的对象不再由程序员实例化，而是通过Spring容器帮我们new指定实例，并且将实例注入到需要该对象的类中。

　 使用Spring框架之后，调用者获取被依赖对象由原来主动获取变成了被动接受，由于由主动变为被动——于是我们称之为控制反转；从Spring容器角度来看，Spring容器负责将被依赖对象赋值给调用者的成员变量——相当于为调用者注入它依赖的实例，所以称之为依赖注入。

此篇为理论部分，下篇为实践部分。