为了账号安全,请及时绑定邮箱和手机立即绑定

Spring IoC有什么好处?

/ 猿问

Spring IoC有什么好处?

九州编程 2019-02-15 15:11:49

Spring IoC有什么好处


查看完整描述

1 回答

?
白板的微信

比如这个例子:
B{
A a=new Aimpl();
//其他代码
}
B{
A a;
//其他代码
public void setA(A a) {
this.a = a;
}12345678910

第一个是直接合成使用A
第二个是用控制反转进行管理
书上只讲理论,我现在都不能体会Spring的IoC和不用相比有什么好处,能具体说一下么?由spring托管有什么好处呢?我现在感觉用spring 的set注入就是看起来代码牛逼点,完全不理解到底有什么优势啊……
ioc的思想最核心的地方在于,资源不由使用资源的双方管理,而由不使用资源的第三方管理,这可以带来很多好处。第一,资源集中管理,实现资源的可配置和易管理。第二,降低了使用资源双方的依赖程度,也就是我们说的耦合度。
也就是说,甲方要达成某种目的不需要直接依赖乙方,它只需要把达到的目的告诉第三方机构就可以了,比如甲方需要一双袜子,而乙方它卖一双袜子,它要把袜子卖出去,并不需要自己去直接找到一个卖家来完成袜子的卖出。它也只需要找第三方,告诉别人我要卖一双袜子。这下好了,甲乙双方进行交易活动,都不需要自己直接去找卖家,相当于程序内部开放接口,卖家由第三方作为参数传入。甲乙互相不依赖,而且只有在进行交易活动的时候,甲才和乙产生联系。反之亦然。这样做什么好处么呢,甲乙可以在对方不真实存在的情况下独立存在,而且保证不交易时候无联系,想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面,避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系,而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。
这就是ioc的核心思想。生活中这种例子比比皆是,支付宝在整个淘宝体系里就是庞大的ioc容器,交易双方之外的第三方,提供可靠性可依赖可灵活变更交易方的资源管理中心。另外人事代理也是,雇佣机构和个人之外的第三方。
在以上的描述中,诞生了两个专业词汇,依赖注入和控制反转
所谓的依赖注入,则是,甲方开放接口,在它需要的时候,能够将乙方传递进来(注入)
所谓的控制反转,甲乙双方不相互依赖,交易活动的进行不依赖于甲乙任何一方,整个活动的进行由第三方负责管理。
IoC最原初的目的就是充分利用OO的多态性,使得通过配置文件而不是在代码里硬编码(hardcode)的方式来实例化对象和装配对象图,这样就有了为不同的客户场景服务的灵活性(不同的客户通过配置文件使用不同的子类)。IoC本质上和插件化代码的思路很接近
举例来说,软件公司只需要维护一套类库,然后通过使用配置文件装配对象图的方式为不同的客户定制不同版本的软件。这些软件可以在功能上、界面上大相径庭,但是区别只在于配置文件
实际上, DI (依赖注入) 和IoC (反转控制) 从使用和实现的角度基本是一样的, 并且spring以前也是被称之为依赖注入的框架的, 只不过后来, 业界思路转变了, 才称之为IoC的
两者的不同点是在于, 从谁的角度去看这个事情
从B的角度, 就是IoC, 表达的意思是, B需要一个提供某某服务的接口, 这时候, B不需要去关心, 谁来提供这个服务, 只需要”声明”说, 我需要一个这个服务, 这个服务需要实现我定义的A的接口, 此所谓反转控制
从A(服务的提供者)的角度, 那就是说, 谁需要我提供的服务, 可以把我注入进去使用, 这时候, 就是DI了
IoC的好处:
从根本上来讲, 无论是IoC还是DI 都是为了 面向接口编程
就像题目中的例子, 第一种方法当然可以, 不过, 如果A的实现发生了变化, 或者有了不同的需求了, 假设A的接口定义了一个存储数据的方法, AImpl实现的方法是把数据存放到文件中
现在, 有另外的团队需要使用B, 而这个团队有不同的需求, 他们不想把数据存放成文件, 而是想存进数据库, 那么, 如果B采用的是第一种实现的话, 那么就只有修改B, 然后重新编译了, 不过这样, 又会导致之前使用B来把数据存放成文件的团队遇到问题, 没法升级
如果采用第二种实现, B里面完全没有AImpl这样的细节, 新的用户如果需要使用数据库的话, 那么只需要实现一个 ADBImpl 然后在配置文件中指定一下就行了
并且, 使用了容器(spring ioc也是一种容器) 之后, 有很多的事情就很方便实现了, 这时候, 就要提到CDI了, 这个规范已经成为Java EE的核心规范了 (spring也是实现了其中的思路)
可以看看CDI的功能, 个人感觉CDI才是最终的发展方向, 它把各种设计模式都玩出花来了
有需要的话可以详细说说CDI
最直接的好处我觉得是测试,如果你的A是一个服务,用第一个就很难测试,因为A在B中声明,B就依赖于A的实现,要测试就需要修改代码。而第二个可以mock一个A注入B,你不用直接用最后需要的A,而是造一个有相似行为的A完成相关的测试,这样B就不依赖A,变成A和B有一个contract,在java中很有可能就是A实现的一个interface
(其实现在应该都叫dependency injection了吧
1.不用自己组装,拿来就用。
2.享受单例的好处,效率高,不浪费空间。
3.便于单元测试,方便切换mock组件。
4.便于进行AOP操作,对于使用者是透明的。
5.统一配置,便于修改。
IOC特性的好处在于 最大限度地降低对象之间的耦合度。譬如:在action中调用DAO访问数据库,传统的做法是,在action中new一个DAO对象,这样对象之间的关系过于紧密,一旦要更改,就麻烦了,不利于维护。就是为了解决这个问题,Spring的IOC特性,应运而生。把对象的创建、和对象的依赖关系控制权都交给了spring,这样,要发生更改时,只需修改一下配置就好了、
(1)少写很多的new(表面上的确这样)
(2)之所以少写new,是因为系统的配置(即第三方的管理)
(3)面向接口,符合OO
(4)系统的可扩展与代码的易维护
首先说说概念:IOC=inverse of control 控制反转,在程序中,被调用类生成的选择控制权从调用它的类中移除,转交给第三方,也就是Spring容器。
举个简单的例子吧,比如你需要一个老婆,传统的设计模式是,我自由恋爱,看上谁娶回家。而IOC的设计模式是甭操心,父母操办,你就翘着二郎腿抽着烟在家等着享受老婆就行了。
IOC设计的好处呢,本来你的目的是有个性生活或者要个娃,传统的设计模式你是不是还得分出精力去找媳妇,显然不符合专注于业务的理念。而IOC的好处就是,大刀阔斧往前走,别的琐事spring容器全给你伺候了。



查看完整回答
反对 回复 2019-03-04

添加回答

回复

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信