Spring系列之 IOC 理论

2020-09-20 本文已影响0人小白菜aaa

简介

本文主要介绍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的程序中，我们使用面向对象编程，对象的创建与对象之间的依赖关系完全硬编码在程序中，对象的创建由程序猿自己控制，

控制反转后讲对象的创建转移给第三方，个人认为所谓控制反转就是：获得依赖对象的方式反转了。

结尾

感谢看到最后的朋友，都看到最后了，点个赞再走啊，如有不对之处还请多多指正。

Spring系列之 IOC 理论

简介

结尾

猜你喜欢

热点阅读