IOC设计原则和核心思想

浏览了很多描述IOC的文章，然而真正IOC解决了什么痛点，大家知道？面试官经常会问道IOC是什么？可能大家一想到的就是英文全拼(Spring 中的IOC英文意思是 Invoke Of Convert （控制反转))而脱口答道 --控制反转，面试官接着问道 控制反转是什么，可能大家会说IOC是一个容器，但是真正的IOC是用来干什么的，以及这种设计思想的出现是在什么场景下演化来的，我想很少人能说的出来！
first：我们来先看下百度百科：
https://baike.baidu.com/item/控制反转/1158025?fr=aladdin

控制反转是一种设计原则，而依赖注入DI是它的一种实现方式；
技术描述：
Class A中用到了Class B的对象b，一般情况下，需要在A的代码中显式的new一个B的对象。
采用依赖注入技术之后，A的代码只需要定义一个私有的B对象，不需要直接new来获得这个对象，而是通过相关的容器控制程序来将B对象在外部new出来并注入到A类里的引用中。而具体获取的方法、对象被获取时的状态由配置文件（如XML）来指定。

这样就解决了依赖方不需要主动去指定引用那一个具体的依赖，而是取决于业务实现，在应用程序的层面去决定具体依赖那一个类或者组件，将依赖的控制权交给了容器，程序层面去控制，我服务消费者(需要调用服务的类)不需要去指定具体依赖哪个类，而是靠XML配置文件的方式去解耦，这也符合了面向接口编程的基本原则，我不需要去关注具体依赖哪个类，方便服务实现的切换，我想最早的场景，就是手动去修改服务器的XML文件，而避免了去修改代码，再重新编译，部署的尴尬；
演变历程：

具体的文章大家可以去看下这位博主的文章：https://www.cnblogs.com/xinhuaxuan/p/6128523.html，很值得推荐，相比许多侃侃而谈的文章，这篇算是真知灼见了！
IOC 的常见实现方式：
构造注入；属性注入，和自动装配@Autowired