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來控制它依賴的對象，現在全部交給了容器來控制。