Java架构师告诉你Spring IoC有什么好处呢

前言：

这个问题也一直困惑我很久，毕竟其他语言没有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）。

写在最后：欢迎留言讨论，加关注，持续更新！！！