2、IOC理论推导

原始的开发模式

1.UserDao接口

2.UserDaoImpl 实现类

3.UserService 业务接口

4.UserServiceImpl 业务实现类

2.1 分析实现过程

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

  1. UserDao接口
    public interface UserDao {
      public void getUser();
    }
    
  2. UserDaoImpl实现类
    public class UserDaoImpl implements UserDao {
      @Override
      public void getUser() {
          System.out.println("获取用户数据");
     }
    }
    
  3. Service接口
    public interface UserService {
      public void getUser();
    }
    
  4. ServiceImpl实现类
    public class UserServiceImpl implements UserService {
      private UserDao userDao = new UserDaoImpl();
    
      @Override
      public void getUser() {
          userDao.getUser();
     }
    }
    
  5. 测试类
    @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后,将对象的创建转移给第三方。所谓的控制反转就是,获得依赖对象的方式反转了,由程序反转给用户本身。

img

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

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

image-20200816001314981

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

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

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇