spring ioc 的好处？？？

原因只是因为 Java 不支持 object 关键词

@Cbdy 啥？

修改 Spring 配置文件能够替换掉 bean 的方法，但新的类总归还是要打包进去。正确的表述应该是"不需要修改一行原有代码，也不需要重新编译旧代码"……感觉是在浮夸吹捧 Spring …

楼上说的是 Java 不原生支持单例

你去关注一下几个关键词：

面向接口编程 /依赖，注入，依赖接口而不是实现，等等

@zjp 嗯，这样说就好理解了，新增的类编译后 重新打包，省掉的是编译原来的代码的时间， 没有很大的代码量的公司确实没有这样的经历。。。谢谢了

ioc，在组织方式上更加灵活，可以完全控制对象的生命周期，而且可以先实现接口不实现类，最后再按类型注入，这样开发过程中就互不干扰，互不依赖。
aop 的好处就不说了

@cloudzhou 我理解这些概念，只是对于这种操作有疑惑：“ 不需要修改一行代码，也不需要重新编译，只需要修改配置文件 spring.txt ，再运行” ， 我好奇在线上怎么进行这种切换呢

@lhx2008 只看标题就回答了吧😂

@zhecaoli #5 我还是学生…只是试过 Spring 里方法替换的功能……
其他楼层都在回答你的标题…这标题误导了……

@zhecaoli 这种意义不大，打包的时间又不用很久，而且大部分都用注解了。

@zjp 也没办法修改了看来，没有 stackoverflow 那么方便

@lhx2008 嗯，基本都用了注解了，也就是说现在 spring ioc 这种免编译的好处 是可以忽略的了？

jar 包运行的时候肯定是已经解压了的，可以替换 class，这种也和 spring 没关系。但是意义不大，具体可以看热更新的一些技术。

我怎么感觉楼上的都偏题了。。。

IOC 只是业务上的解耦. 比如我最近写的一个观察者模式,所有的观察者在 Subject 中可以 Spring 容器启动完毕后自动注入.
这样我新增观察者只需要写一个实现对应观察者接口的类,让 Spring 管理就好了,其他都不用理会.这就是一种解耦.

```java

private void initPaidObserver(ContextRefreshedEvent event) {
Map<String, OrderPaidHandlerObserver> matchingBeans =
BeanFactoryUtils.beansOfTypeIncludingAncestors(event.getApplicationContext(), OrderPaidHandlerObserver.class, true, false);
this.paidObservers = Collections.unmodifiableList(Lists.newArrayList(matchingBeans.values()));
if (this.paidObservers.size() <= 0) {
throw new IllegalStateException("OrderPaidHandlerObserver not found");
} else {
log.info("initPaidObserver finish, observer is {}", matchingBeans.keySet());
}
}

```

你不写单元测试？
如果没有 IOC，没有数据库的情况下要测试 Service 怎么办

简单来说，IOC 的好处就是解耦

建议把 spring 去掉，ioc 不是 spring 特有的。
你去看看宇宙最好的语言写出来的 laravel，照样 ioc+各种依赖注入。