Spring学习笔记-2-IOC

IOC 控制反转.

目录结构

1、IOC理论推导.

原来业务Dao写法.

1. UserDao接口

   public interface UserDao {
       void getUser();
   }

2. UserDaoImpl接口实现

   public class UserDaoImpl implements UserDao{
       @Override
       public void getUser() {
           System.out.println("原始UserDao");
       }
   }

3. UserService业务接口

   public interface UserService {
       void getUser();
   }

4. UserServiceImpl业务实现

   public class UserServiceImpl implements UserService{
   
       private UserDao userDao = new UserDaoImpl();
   
       @Override
       public void getUser() {
           userDao.getUser();
       }
   }

如果是原来的编写方式，在UserServiceImpl写死UserDao的实例化，你会发现

在用户想要更改业务需求时，我们就必须在UserSericeImpl中做响应的修改,导致需要频繁的更改原代码,当向这样的类很多时，就要改动很多源代码

public class UserServiceImpl implements UserService{

//    UserDao userDao = new UserDaoImpl();
    // 有业务需求变化 必须 要修改原代码
    private UserDao userDaoMysql = new UserDaoMySQLImpl();

    @Override
    public void getUser() {
//        userDao.getUser();
        userDaoMysql.getUser();
    }
}

使用IOC的思想.

：我们在UserServiceImpl中设置一个set方法，用于接收外界（用户…）传来的UserDao对象，对userDao进行初始化，这样即使业务有所修改，也不会对UserServiceImpl进行修改

public class UserServiceImpl implements UserService{

    private UserDao userDao;

    @Override
    public void getUser() {
        userDao.getUser();
    }

    public void setUserDao(UserDao userDao){
        this.userDao = userDao;
    }
}

对比.

• 之前，程序是主动创建对象(实例化写死)，控制权在程序员手上（程序员需要根据业务需求变化更改代码）
  • 修改业务需要改动原代码（代码量大，不易维护）
• 使用功能Set注入之后，程序不再有主动性，而是被动的接收对象，控制权在用户手上（给用户一个接口，用户可以自己调用相应的业务功能）
  • 提供set方法接收外界对象，无需改动原代码

这种思想，从本质上解决了问题，我们程序员不用再去管理对象的创建了。系统耦合性大大降低，可以更加专注的在业务的实现上，这是IOC的原型

2、IOC本质.

控制反转IoC（Inversion of Control），是一种设计思想，DI（依赖注入）是实现IoC的一种方法，也有人认为DI是IOC的另一种说法。没有Ioc的程序中，我们使用面向对象编程，对象的创建与对象间的依赖关系完全硬编码在程序中，对象的创建有程序自己控制，控制反转后将对象的创建转移给第三方。获取依赖对象的方式反转了。

• IoC 是Spring框架的核心内容
• 采用XML方式配置Bean的时候，Bean的定义信息是和实现分离的，而采用注解的方式可以把两者合为一体，Bean的定义信息直接以注解的形式定义在实现类中，从而达到了零配置的目的。
• 控制反转是一种通过描述（XML或注解）并通过第三方去生产或获取特定对象的方式。在Spring中实现控制反转的是IOC容器，其实现方法是依赖注入（Dependency Injection，DI）