IOC DI

IoC:Inversion of Control,控制反转
DI:Dependency Injection,依赖注入

要理解上面两个概念,就必须搞清楚如下的问题:

参与者都有谁?
依赖:谁依赖于谁?为什么需要依赖?
注入:谁注入于谁?到底注入什么?
控制反转:谁控制谁?控制什么?为什么叫反转(有反转就应该有正转了)?
依赖注入和控制反转是同一概念吗?

下面就来简要地回答一下上述问题,把这些问题搞明白了,也就明白IoC/DI了。
(1)参与者都有谁:一般有三方参与者,一个是某个对象;另一个是IoC/DI容器(譬如Spring);还有一个是某个对象的外部资源。
Tips:某个对象指的是任意的、普通的Java对象;IoC/DI的容器简单点说就是指用来实现IoC/DI功能的一个框架程序;
对象的外部资源指的就是对象需要的,但是是从对象外部获取的,都统称为资源,譬如,对象需要的其它对象,或者是对象需要的文件资源等。

(2)谁依赖于谁:当然是某个对象依赖于IoC/DI的容器
(3)为什么需要依赖:对象需要IoC/DI的容器来提供对象需要的外部资源
(4)谁注入谁:很明显是IoC/DI的容器把某个对象需要的资源注入此对象
(5)到底注入什么:就是注入某个对象所需要的外部资源
(6)谁控制谁:当然是IoC/DI的容器来控制对象了
(7)控制什么:主要是控制对象实例的创建
(8)为何叫反转:反转是相对于正向而言的,那么什么算是正向的呢?
考虑一下常规情况下的应用程序,如果要在A里面使用C,你会怎么做呢?
一般会使用组合,直接去创建C的对象,也就是说,在A类中主动去获取需要的外部资源C,这种情况被称为正向的。
那么什么是反向呢?就是A类不再主动去获取C,而是被动等待,等待IoC/DI的容器获取一个C的实例,然后反向地注入到A类中
主动去取是正向,被动接收就反向,从正向改为反向,就称为反转

(9)依赖注入和控制反转是同一概念吗?
依赖注入和控制反转是对同一事情的不同角度的描述。
依赖注入是强调某个对象获取需要的资源的方式;控制反转强调的是指某个对象在获取所需资源是主动还是被动
从某个方面讲,就是它们描述的角度不同。
依赖注入是从应用程序的角度去描述,可以把依赖注入描述得完整点:应用程序依赖容器创建并注入它所需要的外部资源;
而控制反转是从容器的角度去描述,描述的完整点就是:容器控制应用程序,由容器反向地向应用程序注入其所需要的外部资源。

IoC/DI的进步是编程思想上“主从换位”的变化。应用程序原来是老大,要获取什么资源都是主动出击,但是在IoC/DI思想中,
应用程序就变成被动的了,被动地等待IoC/DI容器来创建并注入它所需要的资源。

IoC/DI的目标是代码复用、解耦。程序的体系结构也变得非常灵活。

时间: 2024-10-02 09:09:57

IOC DI的相关文章

Spring+IOC(DI)+AOP概念及优缺点

Spring pring是一个轻量级的DI和AOP容器框架. 说它轻量级有一大部分原因是相对与EJB的(虽然本人从没有接触过EJB的应用),重要的是,Spring是非侵入式的,基于spring开发的应用一般不依赖于spring的类. 容器:Spring是个容器,因为它包含并且管理应用对象的生命周期和配置.如对象的创建.销毁.回调等. 框架:Spring作为一个框架,提供了一些基础功能,(如事务管理,持久层集成等),使开发人员更专注于开发应用逻辑. Spring的优点1.降低了组件之间的耦合性 ,

Spring -- IOC/DI 基础概念的理解

Spring -- IOC/DI 基础概念 思维导图: ------------------------------------------------------- IoC/DI 的基本概念 IoC是什么 ? IoC -- Inversion of control, 控制反转   在Java开发中,IoC意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制.IoC是一种让服务消费者不直接依赖于服务提供者的组件设计方式,是一种减少类与类之间依赖的设计原则. 理解IoC的关键是明

深入理解IoC/DI

------------------------------------------------------------------------ 理解IoC/DI 1.控制反转 --> 谁控制谁? 控制什么? 为何叫反转(对应于正向)?哪些方面反转了?为何需要反转? 谁控制谁?  --> IoC/DI容器控制应用程序 控制什么? --> IoC/DI容器控制对象本身的创建.实例化; IoC/DI容器控制对象之间的依赖关系 为何叫反转(对应于正向)? --> 因为现在应用程序不能主动

工厂方法模式与IoC/DI控制反转和依赖注入

IoC——Inversion of Control  控制反转 DI——Dependency Injection   依赖注入 要想理解上面两个概念,就必须搞清楚如下的问题: 参与者都有谁? 依赖:谁依赖于谁?为什么需要依赖? 注入:谁注入于谁?到底注入什么? 控制反转:谁控制谁?控制什么?为何叫反转(有反转就应该有正转了)? 依赖注入和控制反转是同一概念吗? 下面就来简要的回答一下上述问题,把这些问题搞明白了,IoC/DI也就明白了.(1)参与者都有谁: 一般有三方参与者,一个是某个对象:一个

关于依赖注入IOC/DI的感想

之前一直不明白依赖注入有什么好处,甚至觉得它是鸡肋,现在想想,当时真是可笑. 这个想法正如同说接口是没有用处一样. 当整个项目非常庞大,各个方法之间的调用非常复杂,那么,可以想象一下,假设说没有任何的分离模块的想法,各个关系非常的复杂,不便于维护以及查找bug等等.这个时候,就需要一个东西,去将这么多复杂的玩意分离开来,很喜欢的一句话:高内聚,低耦合. 举个栗子,现在一个很简单的功能,可能只需要通过一些方法互相调用就可以实现,OK,那么随着需求的增多,现在添加了几个功能,那么,我们把相同的东西划

对DIP IoC DI的理解与运用

DIP,IoC,DI基本概念 依赖倒置原则(DIP,Dependency Inverse Principle):强调系统的“高层组件”不应当依赖于“底层 组件”,并且不论是“高层组件”还是“底层组件”都应当依赖于抽象.抽象不应当依赖于实现,实现应当依赖于抽象. 依赖(Dependency):组件A如果:①持有B的引用,②调用B的方法,③创建(new)B,则A对B产生依赖. 控制(Control):A依赖B,则B拥有“控制权”,因为B的某种变化可能会引起A的变化. 控制反转(IoC,Inverse

NET Core应用中实现与第三方IoC/DI框架的整合?

NET Core应用中实现与第三方IoC/DI框架的整合? 我们知道整个ASP.NET Core建立在以ServiceCollection/ServiceProvider为核心的DI框架上,它甚至提供了扩展点使我们可以与第三方DI框架进行整合.对此比较了解的读者朋友应该很清楚,针对第三方DI框架的整合可以通过在定义Startup类型的ConfigureServices方法返回一个ServiceProvider来实现.但是真的有这么简单吗? 一.ConfigureServices方法返回的Serv

spring中的IOC/DI的知识点

IOC(Inverse of control):控制反转;其实就是一个装对象的容器,以前我们在controller中调用service中的方法,都要先new 一个service对象,这样不符合模式设计的六大法则中的依赖倒置原则,为了处理这个问题,可以把各层创建对象的工作让spring来完成,spring创建对象都把它放在ioc中 DI:依赖注入:其实与IOC是一回事,只是从不同的角度来看待问题的 实现IOC/DI的技术有: 1.setter注入(最常用) 2.构造方法注入(使用它时,要注意空构造

[Spring系列01]Spring IOC/DI模拟

本文以一个简单的实例大致模拟Spring IOC/DI的运行原理,代码简单分dao,model,service三层.即:dao 与数据库的操作,增删改查等方法model 一般都是javabean对象,例如与数据库的某个表相关联.service 供外部调用,等于对dao,model等进行了包装. 程序结构图如下: 先粘贴部分代码,再进行解释: UserDAO.java package com.ctsh.dao; import com.ctsh.model.User; public interfac

spring--学习之IOC DI

2.1.1  IoC是什么 Ioc-Inversion of Control,即"控制反转",不是什么技术,而是一种设计思想.在Java开发中,Ioc意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制.如何理解好Ioc呢?理解好Ioc的关键是要明确"谁控制谁,控制什么,为何是反转(有反转就应该有正转了),哪些方面反转了",那我们来深入分析一下: ●谁控制谁,控制什么:传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动