常听人说起IOC和Spring，那什么是IOC呢？
IOC可以理解为‘面向接口编程思想’的一种实现方法，通过IOC实现了强制的‘面向接口编程’。
Spring以一种工程化的系统化的方法法，强迫程序员按照架构师的思路去实现class。
举例来说，架构师设计了三种业务对象：用户、数据池、数据元。架构师希望这三种对象分别提供各自的接口出来，让用户可以调用数据池，而数据池可以包含数据元。
架构师如何让程序员了解他要做的事情，并且强迫程序员按照他的设计去写代码呢？
Spring就是这样的一个方式，它按照接口定义了各个类，并且定义了各个类的关系。程序员的class如果写的不对，那么它的类就会‘组装’不进来。由于接口是先于实现而被定义的，因此一旦程序员的实现不正确，很容易定位出是谁的实现有问题。
这也是为什么Java的程序员很便宜而且必须有架构师这个职位，Spring能否有效的工作起来取决于架构师的设计；程序员的主要工作就是填空。
这也是为什么大家说Java重的原因，做一个东西必须设计出接口出来。如果很敏捷的想要对接口进行改变，则IOC就很吃力了。‘面向接口编程’所会遇到的问题，就是IOC会遇到的问题。
因此，是否要采用Spring和IOC，你只要问自己一个问题“我希望在这个产品中采用面向接口的编程方式”吗？这个问题会更容易回答。
作为对比，C++里面没有IOC是怎么解决这种问题呢？一般有这几种方式：1，把程序切成多个小程序，每个程序对外提供简单服务；2，写设计文档，设计文档里面定义各个类的作用和接口；3，做一个概要设计，然后小组里面进行敏捷编程。这三种方式各有优缺点，要根据项目以及团队的情况来选择。
对比之下可以发现，Java确实比C++更适合写逻辑复杂的大块头。Spring这样的框架引入了硬性的约束，降低了沟通成本。（此外C++还有一个内存越界的问题）
然后我们也可以发现，超大规模的系统仍然要采用切割的方式，则Java擅长做大块头的特点就没什么优势了。因为大块头同时也会增加超大规模系统的维护难度。
现实世界也是如此，Java适合开发企业应用里面揉成一团的大块头。超大规模的系统则形形色色，用什么技术的都有了。