Spring(3):IOC--“控制反转”的剖析
原创
©著作权归作者所有:来自51CTO博客作者后台技术汇的原创作品,请联系作者获取转载授权,否则将追究法律责任
普通的业务实现方法,如下伪代码:
/*
* 接口,定义了持久化方法
* */
public interface UserDao{
/**
* 保存方法
* */
public void save();
}
/**
* DAO实现类,实现具体的操作
* */
public class UserDaoImpl implements UserDao{
public void save(){
//说明作用
System.out.println("Have saven user data.");
}
}
/**
* 用户业务类,实现对User功能的业务管理
* */
public class UserServiceImpl implements UserService{
//实例化依赖的UserDao对象
private UserDao dao = new UserDaoIpml();
public void addNewUser(User user){
//调用UserDao的方法
dao.save();
}
}
上面代码有哪些问题呢?
(1)UserServiceImpl 和 UserDaoImpl 存在依赖关系,彼此高度耦合。(假如需求变化了,要改UserDaoImpl ,那UserServiceImpl 也要做修改);
(2)难测试,可扩展性和维护性很低。
利用“控制反转”的思想解决吧!
/**
* 增加了用户DAO工厂
* */
public class UserDaoFactory{
//负责创建用户DAO实例
public static UserDao getInstance(){
//省略具体步骤
}
}
/**
* 用户业务类,实现对User功能的业务管理
* */
public class UserServiceImpl implements UserService{
//通过工厂获取DAO对象
private UserDao dao = UserDaoFactory.getInstance();
public void addNewUser(User user){
//调用save方法
dao.save();
}
}
就是说,UserServiceImpl 不再依赖自身代码去获得所依赖的具体DAO对象,而是把这个工作交给了“第三者”---UserDaoFactory,从而避免了和具体实现类
DAO的UserDaoImpl耦合。
因此,在获取依赖对象的这件事上,“控制权”发生了“反转”---由UserDaoImpl 转到了 UserDaoFactory 。