原来的业务逻辑：用户调用业务层，不接触 dao 层
- UserDao 接口
- UserDaoImpl 实现类
- UserService 业务接口
- UserServiceImpl 业务实现类
用户需求的改变，会导致我们根据用户的需求修改原代码，在代码量很大的情况下，代价很大，此时控制权在码农这里
定义一个 Set 接口
//set动态实现值的注入
public void setUserDao(UserDao userDao) {
this.userDao = userDao;
}
通过 Set 注入，程序变为被动的接受对象，用户可根据需求的不同调用不同的实现方法
这种思想就是IOC的原型，码农无需管理对象的创建，只需专注业务实现，降低了系统的耦合性
个人理解：和汽车挂挡一个道理，码农可以理解为汽车厂商，用户理解为司机，接口理解为挡位。
不使用 IOC 思想时：司机想挂前进档，需要厂商给调到前进挡，司机想挂倒挡，厂商给调到倒挡。此时控制权在厂商手里，司机每换一次挡都要厂商给调一次，是不是很麻烦？
使用 IOC 思想时：厂商提供变速箱，理解为码农给提供了不同挡位的接口，用户想换挡可以根据自己的需求自己去调，不需要厂商来处理，此时控制权在司机手里。
厂商（码农）只用负责怎么让你换挡（业务实现），至于司机（用户）挂哪个挡（需求），厂商（码农）不需要在司机（用户）每换一次挡都要去给用户调一次挡（更改代码）
