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