普通的业务实现方法,如下伪代码:


/*
* 接口,定义了持久化方法
* */
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  。