简介
本文主要介绍ioc理论,首先先对其进行推导,而后进行具体过程的概括。
ioc 理论推导
1,UserDao接口
2,UserDaoImpl 实现类
3,UserService业务接口
4,UserServiceImpl 业务实现类
public interface UserDao {
void getUser();
}
UserDao接口的实现方式一
public class UserDaoImpl implements UserDao {
public void getUser() {
System.out.println("默认获取用户数据");
}
}
UserDao接口的MySQL获取数据方式
public class UserDaoMysqlImpl implements UserDao {
public void getUser() {
System.out.println("Mysql获取用户数据");
}
}
UserDao接口的Oracle获取数据方式
public class UserDaoOracleImpl implements UserDao {
public void getUser() {
System.out.println("Oracle获取用户数据");
}
}
业务层:
public interface UserService {
void getUser();
}
业务实现层:
public class UserServiceImpl implements UserService {
private UserDao userDao = new UserDaoImpl();
public void getUser() {
userDao.getUser();
}
}
测试:
public class MyTest {
public static void main(String[] args) {
// 用户实际调用的是业务层,dao层他们不需要接触
//
UserService userService = new UserServiceImpl();
userService.getUser();
}
}
在业务实现层 UserServiceImpl 类中,调用的是UserDao接口的实现方式一,如果用户想要通过MySQL的方式去获取数据,就需要改 UserServiceImpl 类:
private UserDao userDao = new UserDaoMysqlImpl();
想换成Oracle的方式去获取数据也是一样的方式去修改:
private UserDao userDao = new UserDaoOracleImpl();
这样用户的需求的变动就会影响我们原来的代码,我们需要根据用户的需求去修改代码!!!
如果程序代码量十分大,修改一次的成本十分昂贵!这种设计的耦合性太高,牵一发而动全身。
我们可以按照如下方式去修改UserServiceImpl 业务实现类,通过set方法注入,
public class UserServiceImpl implements UserService {
//方式一
//private UserDao userDao = new UserDaoImpl();
//方式二
//private UserDao userDao = new UserDaoMysqlImpl();
//方式三
//private UserDao userDao = new UserDaoOracleImpl();
//方式四 利用set方法进行动态实现值的注入!!!
private UserDao userDao;
public void setUserDao(UserDao userDao) {
this.userDao = userDao;
}
public void getUser() {
userDao.getUser();
}
}
用户的调用:
public class MyTest {
public static void main(String[] args) {
// 用户实际调用的是业务层,dao层他们不需要接触
//
UserService userService = new UserServiceImpl();
// 如果用户想调用MySQL的方式去获取数据,在现在的这个版本的基础上,只能改 UserServiceImpl 实现类中的UserDao的实现类
// private UserDao userDao = new UserDaoImpl();
// 改成 private UserDao userDao = new UserDaoMysqlImpl();
// 如果用户又想调用Oracle的方式去获取数据,又要改 UserServiceImpl 里面 UserDao的实现类
//思考:怎么在不改变UserServiceImpl 类的情况下,在客户端用户调用的时候动态改变 UserDao的实现类,客户端用户传什么就调用什么?
//
// --- 在 UserServiceImpl 通过set方法动态注入UserDao的实现类
//((UserServiceImpl) userService).setUserDao(new UserDaoImpl());
((UserServiceImpl) userService).setUserDao(new UserDaoMysqlImpl());
userService.getUser();
}
}
我们使用一个Set接口实现,已经发生了革命性的变化!!!
-
之前,程序是主动创建对象!控制权在程序猿手上!!!
-
使用了Set注入之后,程序不在具有主动性,而是变成了被动的接收对象!
这种思想,从本质上解决了问题,我们程序猿不用再去管理对象的创建了!!!系统的耦合性大大降低,可以更加专注的在业务的实现上!这是IOC的原型!
IOC本质
控制反转IoC(Inversion of Control),是一种设计思想,DI(依赖注入)是实现IOC的一种方法,也有人认为DI只是IOC的另一种说法。
没有IOC的程序中,我们使用面向对象编程,对象的创建与对象之间的依赖关系完全硬编码在程序中,对象的创建由程序猿自己控制,
控制反转后讲对象的创建转移给第三方,个人认为所谓控制反转就是:获得依赖对象的方式反转了。
结尾
感谢看到最后的朋友,都看到最后了,点个赞再走啊,如有不对之处还请多多指正。
网友评论