2、IOC理论推导 – 像一名拾荒者

原始的开发模式

1.UserDao接口

2.UserDaoImpl 实现类

3.UserService 业务接口

4.UserServiceImpl 业务实现类

2.1 分析实现过程

先用原始的方式写一段代码

UserDao接口

public interface UserDao {
  public void getUser();
}

UserDaoImpl实现类

public class UserDaoImpl implements UserDao {
  @Override
  public void getUser() {
      System.out.println("获取用户数据");
 }
}

Service接口

public interface UserService {
  public void getUser();
}

ServiceImpl实现类

public class UserServiceImpl implements UserService {
  private UserDao userDao = new UserDaoImpl();

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

测试类

@Test
public void test(){
  UserService service = new UserServiceImpl();
  service.getUser();
}

如果在UserDao 的实现类中增加一个方法

public class UserDaoMySqlImpl implements UserDao {
   @Override
   public void getUser() {
       System.out.println("MySql获取用户数据");
  }
}

如果我们要去使用这个方法的话，我们就需要去Service实现类里面去修改对应的实现方法

public class UserServiceImpl implements UserService {
   private UserDao userDao = new UserDaoMySqlImpl();

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

假设，我们在次之上在去增加一个UserDao实现方法

public class UserDaoOracleImpl implements UserDao {
   @Override
   public void getUser() {
       System.out.println("Oracle获取用户数据");
  }
}

那么我们要去使用这个方法时，又需要去Service实现类里面去修改对应的实现方法。如果我们的这种需求非常大，这种方法根本不适用，因为每次的需求变更，都需要去修改大量的实现代码，这种设计耦合性太高，牵一发而动全身

解决方法

我们可以在需要用到他的地方，不去实现它（可以说不去给他进行实例化），而是留出一个接口。

public class UserServiceImpl implements UserService {
   private UserDao userDao;
// 利用set实现
   public void setUserDao(UserDao userDao) {
       this.userDao = userDao;
  }

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

再次进行测试

@Test
public void test(){
   UserServiceImpl service = new UserServiceImpl();
   service.setUserDao( new UserDaoMySqlImpl() );
   service.getUser();
   //那我们现在又想用Oracle去实现呢
   service.setUserDao( new UserDaoOracleImpl() );
   service.getUser();
}

虽然两次结果是一样的，但是，从根本上发生了改变。以前所有的东西都是程序员已经new好的，用户无法自行更换需求，如果需要更换需求，就要去修改其源码，换句话说，系统的主动权在程序员手中，在源码中。后者，因为预留了set接口，使得用户可以根据自己的需求来调用相应的实现方法，换句话说，系统的主动权在用户手中。程序不用去关心怎么去new，怎么去实现，只负责提供一个接口而已。

这种思想，从本质上解决了问题，程序员不用再去管理对象的创建，更多的去关注业务的实现，耦合性大大降低，这就是IOC的原型！

2.2 IOC本质

**IOC 是一种设计思想，DI（依赖注入）是实现IOC的一种方法 **，也会有人认为DI只是IOC的另一种说法。没有IOC的程序中，我们使用面向对象编程，对象的创建与对象之间的依赖关系完全强行编码在程序中，对象的创建由程序自己控制，使用IOC后，将对象的创建转移给第三方。所谓的控制反转就是，获得依赖对象的方式反转了，由程序反转给用户本身。

IOC是Spring 框架的核心内容，使用多种方式完美的实现IOC，可以只用XML配置，也可以使用注解，新版本的Spring也可以零配置实现IOC。

Spring容器在初始化时先读取配置文件，根据配置文件或元数据创建与组织对象存入容器中，程序使用时再从IOC容器中取处需要的对象。

采用XML方式配置Bean的时候，Bean的定义信息是和实现分离的，而采用注解的方式把两者合为一体，Bean的定义信息直接一注解的形式定义在实现类中，从而达到了零配置的目的。

控制反转是一种描述（XML、注解）并通过第三方生产或获取特定对象的方式，在Spring中实现控制反转的是IOC容器，其实现方式是依赖注入（DI）。

2.1 分析实现过程

2.2 IOC本质

发送评论 编辑评论

发送评论编辑评论