前言:

这个问题也一直困惑我很久,毕竟其他语言没有IOC也活的很好。

但是Spring在当时能够一统江湖,跟IOC真的有很大的关系。

在没有IOC的时代,New代表一切,女朋友都是可以New出来的。

那么,倒底为什么要去除掉New,想出来IOC这种绝世设计呢?

按照上帝视角的原则,我们还是先看一下,New会出现什么问题,再去推导一下,IOC有没有解决掉这个问题。

正文:

暗灭大人曾经说过,软件开发分成以下几个阶段:

  • 面向功能编程
  • 面向复用编程
  • 面向性能编程
  • 面向未来编程
  • 面向造物编程

大部人都停留在面向功能编程的阶段,而New,就是用来完成面向功能编程的常用手段。

同样的,在面向功能编程阶段还有以下特征:

  1. 耦合度高
  2. 代码行数长,很少做抽象
  3. 硬编码多,没有扩展性
  4. 数据和代码混在一起,无法复用
  5. Hack代码到处都是
  6. 不考虑未来需求的变更

New的问题就在于是,如果说有多个地方调用了一个方法,而我又要更改这个方法,怎么办?

最简单也是最容易理解的,就是短信服务。

在短信服务这个场景中,短信通道经常是不可控的,会被替换的,又是整个系统,特别是在用户登录的过程中非常重要的环节。

运营商是把通道卖给各种公司,各种公司用通道构造成一个个的短信服务,这些短信服务公司,接口不一致,实现方案不一样,没什么标准化。

而且短信又是最容易被用做短信炸弹的,用户投拆之后,通道就会被封,老板一着急,肯定是希望说我要换短信通道 。

这就是需求的来源,很简单,最终形成的结论就是我要换短信通道。

怎么个换法呢?系统里使用短信通道的地方会有很多,注册需要,修改密码需要,后台管理群发短信的时候可能也需要,有一些特殊提醒需要发短信,还是需要。

多个环节,要改动实现类,怎么改?比如说我要从容联的通道改到创蓝的通道。

重新改代码都是需要调试,接口不一致,参数不一致,往往会导致出一些问题。

那么要改进怎么解决呢?

第一件事就是要学习秦始皇,统一哈。

怎么统一呢?用Java的接口和实现类。我把所有短信提供的服务,声明出来,这叫作接口,就是用来告诉调用方,你需要传给我什么参数,我需要返回给你什么参数。

这是接口。

那么对应的,就是有实现类。

接口和实现类,其实也很常见。比如说,http协议,CSS等都是一波人定协议,另外一波人遵循这个规范去做实现。

接口和实现有这个意思。

所以第一步很关键点就在于是,我们先把接口和实现抽离,这样的好处是什么呢?

无论你的短信通道是什么样的方式,是Http的还是Socket的,还是其他的方式,对外而言,统一暴露的就是一致的接口。手机号和内容。

好了第一步有了。这样看起来就好多了。这个时候仍然是New。

只不过,换类的时候,因为接口是一致的,所以我只需要改

 SMSService smsService= new SMSServiceRongLianImpl();
int code = smsService.sendMsg(phone,msg);

变成

  SMSService smsService= new SMSServiceChuangLanImpl();
int code = smsService.sendMsg(phone,msg);

不影响其他的实现。是不是看起来比之前要好很多了?

毕竟大家这个时候统一使用的是smsService,而根本不关心这个smsService倒底是哪一个实现类。

这个时候,一个大胆的想法就出来了。

既然我不关心smsService是由哪一个实现类构成的。

我为什么要在一个方法被调用的时候去实例化它呢?为什么我不在一开始,我的类构造的时候就创建他呢?

先是有一个私有的属性。

private SMSService smsService;

然后在构造函数中

super();
this.smsService= new SMSServiceChuangLanImpl();

这样的原来的代码只有一句

 int code = smsService.sendMsg(phone,msg);

这样是不是让我们的业务代码更简洁了?而且很有包办婚姻的快感,你根本不用自己谈恋爱,父母给你定好你就完成你的洞房任务就好了。

想换老婆?对不起,先要让你的父母同意,只要你的父母同意了,随便你换。

总之,你就是要和你的媳妇结婚洞房。

到了这里,其实第三步已经很清楚了。

我既然可以用构造函数实例化,可不可以用Set方法,把构造函数省去,用外部配置来完成smsService的实例化呢?

这样的好处是什么呢?

在我的调用者代码中,完全不需要知道smsService倒底是认谁,父母之命,媒妁之言。

通过配置文件或者是Annonation的方式,将实现类注入到调用者那里去,这其实才是IOC的核心。

所以IOC的好处,就是分成三个阶段来看,离不开接口和实现的设计模式。

  1. 统一第三方服务的参数和返回值,抽像出来接口。
  2. 将原来方法中对接口实例化的代码剥离出来到构造函数中。
  3. 通过配置文件,可以做到改变实现类,而不改变任何一个调用者的代码(IOC)。

写在最后:欢迎留言讨论,加关注,持续更新!!!

最新文章

  1. spring定时器,当遇见半小时的情况时
  2. Java——List集合
  3. StyleCop学习笔记——自定义规则
  4. OpenCV 连接 Android IP摄像头
  5. oc-27-@property的参数
  6. spring slf4j log4j maven
  7. LeetCode——17. Letter Combinations of a Phone Number
  8. StatefulSet
  9. day7 [id],[is],编码
  10. 一步一步配置 Dell OME 监控 Dell 服务器硬件报警
  11. 任务调度框架FluentScheduler简介
  12. 设计模式-单例模式(Singleton Pattren)(饿汉模式和懒汉模式)
  13. linux:进程概念
  14. 学习笔记之数据库Database
  15. 大数据分析系统Hadoop的13个开源工具
  16. 解决 centos 7 部署 tomcat 后外部不能访问应用(端口、防火墙)
  17. vuex到底是什么?
  18. 移动端页面弹幕小Demo实例说明
  19. unix基础杂谈
  20. python入门20 导入模块(引包)

热门文章

  1. Mysql读写分离(Mycat版)
  2. oracle数据库死锁原因及分析
  3. LNMP一键环境安装多PHP版本共存的方法
  4. linux下的进程通信之管道与FIFO
  5. charles 偏好设置
  6. 三节课MINI计划第五周
  7. 京东宙斯平台使用方法(accesstoken,appkey,appsecret参数和SDK的获取)
  8. Zookeeper学习之Watcher事件类型和ZK状态
  9. Redis SETNX实现分布式锁
  10. 多文件上传,添加重复文件时无法触发onchange事件。