ioc的基础思想 狂神

目录

1、 分析实现

2、 IOC本质 


1、 分析实现

我们先用我们原来的方式写一段代码 .

  1. 先写一个UserDao接口
    public interface UserDao {
        public void getUser();
    }

  2. 再去写Dao的实现类
    public class UserDaoImpl implements UserDao {
        @Override
        public void getUser() {
            System.out.println("获取用户数据");
        }
    }

  3. 然后去写UserService的接口
    public interface UserService {
        public void getUser();
    }

  4. 最后写Service的实现类
    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获取用户数据");
        }
    }

    紧接着我们要去使用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获取用户数据");
        }
    }

    那么我们要使用Oracle , 又需要去service实现类里面修改对应的实现 . 假设我们的这种需求非常大 , 这种方式就根本不适用了,  每次变动 , 都需要修改大量代码 . 这种设计的耦合性太高了, 牵一发而动全身 .要想改变的话,我们的ioc就出现了。

  6. 我们可以在需要用到他的地方 , 不去实现它 , 而是留出一个接口 , 利用set , 我们去代码里修改下 .使用DI注入(set方法)

    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();
    }

    小结;大家有没有发现我们程序之间的耦合降低了,程序的控制权反转了,现在程序只提供一个接口,并没有掌控其他的,具体的实现是由我们自己来操作,这就是所谓的控制反转(IOC),spring的两大特性之一,可以把IoC模式看作工厂模式的升华;-----------------------------把IoC容器看作是一个大工厂,只不过这个大工厂里要生成的对象都是在XML文件中给出定义的。利用Java 的“反射”编程,根据XML中给出的类定义生成相应的对象。从实现来看,以前在工厂模式里写死了的对象,IoC模式改为配置XML文件,这就把工厂和要生成的对象两者隔离,极大提高了灵活性和可维护性。

    IoC中最基本的Java技术就是“反射”编程。通俗的说,反射就是根据给出的类名(字符串)来生成对象。这种编程方式可以让应用在运行时才动态决定生成哪一种对象。反射的应用是很广泛的,像Hibernate、Spring中都是用“反射”做为最基本的技术手段。

    在过去,反射编程方式相对于正常的对象生成方式要慢10几倍,这也许也是当时为什么反射技术没有普遍应用开来的原因。但经SUN改良优化后,反射方式生成对象和通常对象生成方式,速度已经相差不大了(但依然有一倍以上的差距)。

2、 IOC本质 

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

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

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

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值