依赖注入原理，作用，注入方式
前言
上一章我们讲到了IOC和DI概述：
https://blog.csdn.net/qq_34598667/article/details/83275560
这一章接上一章继续讲
依赖注入（Dependency Injection）是用于实现控制反转（Inversion of Control）的最常见的方式之一。本文主要在于介绍依赖注入的含义以及原理，为初学者理清头绪
为什么需要依赖注入？
第一个问题，上一章我们主要介绍了控制反转的含义，依赖注入实现了控制反转，那么控制反转的作用是什么？——解耦
那么问题有来了，依赖注入如何实现解耦呢?
首先我们来看一下在没有使用依赖注入下的代码，顺便给大家回顾一下耦合的概念
什么是耦合度？
对象之间的关系，通常说当一个模块(对象)更改时也需要更改其他模块(对象)，这就是耦合，耦合度过高会使代码的维护成本增加。要尽量解耦
举例说明:
public class UserService{
//创建dao接口引用指向实现类对象--直接创建对象
private UserDao userDao=new UserDaoImpl();
//调用dao方法 返回一个User对象
public User login(String userName,String password){
return userDao.login(userName,password);
}
}
仔细观察上述代码：
我们在UserService中创建了一个登陆的login方法，但是实际上完成登陆功能的是UserDaoImpl的登录login方法。我们使用UserDaoImpl的login方法时是直接创建了一个属性UserDao的方式（也有人使用无参构造，在无参构造中使用new创建对象）
那么问题来了，如果现在我需要修改UserDaoImpl的构造方式，在实例化时添加一个属性作为参数，那么我不仅要修改UserDaoImpl中的代码，还要修改所有与UserService中相同的创建UserDaoImpl类型对象的代码。
这种在UserService中创建UserDaoImpl的方式，不仅让UserService依赖于UserDao接口，还依赖于UserDaoImpl。这种就是耦合度过高的体现，也是依赖注入需要解决的问题。
耦合度过高带来的问题
1、修改一处代码会导致很多代码都要修改，修改不方面
2、无法单独测试
3、可读性差（如果一段代码不便于测试，那么它一定不便于阅读）
依赖注入的方式
拔掉外衣看依赖注入，其实它并不复杂，相反其实我们在很多地方都写过，这里介绍一下依赖注入的三种方式：
1）构造器注入
我们修改一下上面的代码，让UserService只依赖于UserDao接口，而不依赖与UserDaoImpl实现类
public class UserService{
//创建dao接口引用指向实现类对象--直接创建对象
private UserDao userDao;
//使用有参构造方法
public UserService(UserDao userDao){
this.userDao=userDao;
}
}
2）setter注入
同样的，我们也可以使用增加一个setter的方式来传入一个创建好的UserDaoImpl对象
public class UserService{
//创建dao接口引用指向实现类对象--直接创建对象
private UserDao userDao;
public void setUserDao(UserDao userDao){
this.userDao=userDao;
}
}
3）接口注入
接口注入是使用接口来提供setter方法，首先得创建一个接口
public interface InjectDao{
void injectDaoImpl(UserDao userDao);
}
然后让UserService实现该接口
public class UserService implements InjectDao{
//创建dao接口引用指向实现类对象--直接创建对象
private UserDao userDao;
public void injectDaoImpl(UserDao userDao){
this.userDao=userDao;
}
}
最后，重点是我们要根据不用的框架来完成依赖注入。
总结
把对抽象接口类型的对象的赋值放在类外面，把new出来的对象放在外面传入进来，那就不用依赖具体的实现类。
下一章，Spring中完成依赖注入的方式：
https://blog.csdn.net/qq_34598667/article/details/83308071