SpringIOC 理论推导

UserDao接口

public interface UserDao {
    void say();
}

UserDaoImpl实现类

public class UserDaoImpl implements UserDao {
    public void say() {
        System.out.println("我想使用默认数据库");
    }
}

UserService接口

public interface UserService {
    void say();
}

UserServiceImpl实现类

如以上代码如果当前业务跟代码逻辑一样没有任何问题输出 我想使用默认数据库

如果后面有需求我想使用MySQL数据库Oracle数据库等等 有一种方法 service实现类多写几个实现MySQL数据库Oracle数据库再调用对应的接口即可如果有成千上万个类似的需求 是不是要写成千上万个？还有一种 将userDao的引用指向业务想要的那么如果频繁修改 业务逻辑代码也能相对应的改麻烦不说且还容易出问题

所以为了解决工作不便需要转变一下思路能不能让private UserDao userDao动态化就像我是mysql userDao就是Mysql 我是oracle userDao就是oracle
SpringIOC 理论推导-LMLPHP

新增MySQL Oracle业务

public class UserMysqlImpl implements UserDao {
    public void say() {
        System.out.println("我想使用Mysql数据库");
    }
}


public class UserOracleImpl implements UserDao {
    public void say() {
        System.out.println("我想使用oracle数据库");
    }
}

测试

如图所示就是这样一个改动加了一个set方法整个代码逻辑就变得很清楚需求是什么我们就传入什么
以前userDao的控制完全在程序本身 设置的什么就是什么没有可扩展性

现在对象的创建或者说需求的实现发生了反转 程序被动的接收userDao的值程序不需要知道userDao什么时候创建的什么时候传入进来的只需要把最终的结果返回出来就好了

IOC控制反转 控制什么反转了? 创建对象的控制权反转了 以前创建对象的主动权和创建时机由程序把握 现在这种权力反转给其他方了

wwbao

SpringIOC 理论推导