spring源碼已經看了很久了，在對spring源碼越來越熟悉的同時，也想對這一次的源碼學習做個階段性的總結。這次總結也不會一次寫完，會在後續逐漸完善。
spring與設計模式
spring對于設計模式的應用，可以說非常的多。在分析spring源碼時候，我也常常考慮，底層的反射、xml分析、依賴注入的基本原理、所謂的控制反轉，這些原理說出來，現在我也基本明白。
那麼假設在我了解這些原理的基礎上，讓我來寫spring，
我寫出來的和spring源碼有什麼差距呢？
我想其中非常大的一個差距就是對于設計模式的應用吧。是以這次分析，我先會從設計模式的角度來看下spring究竟做了啥。
設計模式六大原則
學設計模式時候，我們知道設計模式有六大原則。spring源碼再如何抽象封裝，究其根本，都是向這六大原則靠齊，是以先列下這六大原則。
單一職責原則：一個類隻幹一件事（引起類變化的原因隻有一個）
裡氏替換原則：能使用基類的地方，一定都能使用子類
依賴倒置原則：依賴于抽象而不依賴于細節（面向接口程式設計）
接口隔離原則：接口盡可能小（要為各個類建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用）
迪米特法則：一個對象應該對其他對象保持最少的了解。
開閉原則 ：一個類應該對擴充開放，對于修改關閉（如果需要修改或新增功能，盡可能不要修改舊的代碼）
委派模式的應用
在AbstractAutowireCapableBeanFactory執行個體化Bean時候（擷取了類的各種資訊，包括要建立的類是哪個）
這裡的邏輯大概簡化下，寫成僞代碼
1）根據入參資訊等找到對應要使用的構造函數（可能有多個構造函數）
2）如果找到了，使用該構造函數進行初始化
3）如果找不到，使用預設構造函數初始化
就這樣的邏輯，我們來看看spring是怎麼實作的
autowireConstructor方法委派給ConstructorResolver
instantiateBean 方法委派給InstanitationStrategy
類圖其實挺像政策模式的 = = 這裡我們不管委派模式與政策模式的差別，隻看它這樣設計的核心——單一職責原則 + 開閉原則：
1）一個類隻幹一件事，InstantiationStrategy專心做初始化的類的事情，而AbstractAutowireCapableBeanFactory做createBean相關的
邏輯組裝
。如果建立類的邏輯有變化，createBean的組裝邏輯無需改變。相反也一樣。
2）開閉原則，假想我們建立類的方式有改變了，比如我希望建立類的方式不是簡單地使用反射調用下構造函數，我希望生成的是一個代理類。（這樣不就實作了aop？）那得怎麼做呢？增加一個InstantiationStrategy的實作，AbstractAutowireCapableFactory替換所使用的實作。就好了。完美的遵守了開閉原則。