Spring底层容器创建实例的实现思路和我们上面写的类似，也是使用了工厂模式加上反射。由于反射创建对象的性能比较底，Spring在创建对象的时候，将对象放到了缓存上，下一次如果创建相同对象时，Spring不会进行反射，Spring会从缓存中直接将对象取出返回。
工厂模式+反射并不是IOC（控制反转）和DI（依赖注入）。
配置文件的变化是否违背OCP原则？
不违背。配置文件的变化是允许的，并不违反OCP
配置文件其实是属于系统外部的，而不属于代码本身，可以将它理解成用户的输入，这块本身就是需要改变的。
例如将这边的name改成从配置文件中读取，配置文件改变了，这块代码依旧是不需要改变的。
使用Spring的IOC和DI的时候都是更改配置文件
工厂模式+反射已经可以实现OCP原则，那么为什么我们还需要IOC和DI？
我们的代码里依旧还是调用了具体的工厂类，调用工厂类的方法来获取实例。是否可以不需要工厂类就可以获得实例呢？这就是IOC和DI要解决的问题。
Spring的IOC和DI机制就是提供了一个容器，直接给你一个实例好的对象。
IOC的示例：
A类对C类存在依赖。如果我们的软件足够复杂，那么类与类之间的相互引用(依赖)是非常多的。类与类之间复杂的依赖，使得代码没有办法很好的实现OCP。要是某个类需要更改，需要更改特别多的地方。
需要更改的原因就是在代码里出现了具体的new。那么Spring就提供一个容器，将C实例化的对象给类A，让A直接来使用（依赖注入）。这时候A就可以直接使用c对象的方法。c对象不会为空，因为IOC容易会帮助你实例化这个c对象。
对比工厂方法，是我们在代码中动态的向工厂要一个对象，而现在是IOC容器主动将对象注入给我们。（控制反转）
注意：这边的C类应该是一个接口或者一个abstract抽象类。
为什么引入容器后可以让系统变得稳定？
我们的程序是由多个类之间相互依赖组成的，一旦其中一个类出现了问题，或者需要进行替换，那么就会导致程序别的类间也要进行修改替换。违背了OCP原则。
当我们引入容器，全部的依赖关系由容器来进行管理，每个类依赖的是接口，完全由容器来决定究竟是哪个类对象注入进去。这时候我们想要使用别的类来替换调A类，就可以直接替换，不需要再对别的类进行修改。这时候所有的类是松耦合的。每个类之间不再有依赖了。
DIP依赖倒置到底是什么？
DIP的思想即抽象不应该依赖细节，细节应该依赖抽象。强调的就是面向抽象编程。比如让代码去依赖一个接口。
DI依赖注入的意义？
对象与对象的相互作用，构成了整个系统。对象与对象的相互作用就会产生依赖。DI就是让容器将类所依赖的对象注入进去。
注入的方式：属性注入、构造注入
DI依赖注入的原理？
Spring容器就是工厂模式+反射机制去实现的。系统中所有对象的实例化都是由容器来进行的。容器在实例化类的时候，调用该类的set方法或者构造函数，将这个类依赖的对象赋值进去。
比如容器的实现形式：（这边new用反射做）
容器干的事情就是实例化对象，然后将有依赖关系的对象进行注入。容器的作用是在装配对象。（A类依赖于IC接口，这时候C和C1类都实现了IC接口，A类不关心到底是哪个类对象注入进来。由容器来决定究竟是哪个类对象注入给A，所以类与类之间的耦合度是非常低的）
IOC？
IOC（控制反转）思想是一种抽象的模糊的概念，DI是IOC思想的一种实现。
在类A中实例化类C，称A是C的主控类。那么加入了DI之后，容器就变成了主控方。这样就实现了控制反转，原来是A来控制它依赖的对象，现在全部交给了容器来控制。
