控制反轉(IoC) ？ 工廠模式？

                                            

 

         不知道你們還記不記得當年程傑的《大話設計模式》了，最近一直想搞明白控制反轉究竟是怎麼回事，剛剛以爲高大上了一點，而後再進一步去學習去對比的時候才發現，之前早就接觸過這類的思想，設計原則的依賴倒轉和設計模式的工廠方法都很好的體現了這種思想，火燒眉毛的想要跟你們分享一下啦！

 

1、依賴倒轉原則

 

A.高層模塊不該該依賴低層模塊。兩個都應該依賴於抽象。

B.抽象不該該依賴細節，細節應該依賴於抽象。說白了就是，要針對接口編程，不要對實現編程。

        在控制反轉的原理中，咱們瞭解到，咱們將對象的實例化放到了容器中，在產品實現的時候，咱們直接調用接口，即容器將其所依賴的對象的引用傳遞到產品代碼中。IoC管理對象間的依賴關係，產品代碼只須要針對接口編程，而再也不依賴於具體實現。與依賴倒轉原則一模一樣。

 

                           

2、工廠方法模式

 

        定義一個用於建立對象的接口，讓子類決定實例化哪個類。工廠方法使一個類的實例化延遲到其子類。

工廠方法遵循開放-封閉原則，而且保持了封裝對象建立過程的優勢。

        咱們能夠把IoC模式看作是工廠模式的昇華，把IoC看作是一個大工廠，只不過這個大工廠裏要生成的對象都是在XML文件中給出定義的，而後利用Java的「反射」編程，根據XML中給出的類名生成相應的對象。從實現來看，IoC是把之前在工廠方法裏寫死的對象生成代碼，改變爲由XML文件來定義，也就是把工廠和對象生成這二者獨立分隔開來，目的就是提升靈活性和可維護性。

 

                   

 

3、反射

 

 

        工廠方法也有缺點，就是每加一個產品，就須要加一個產品工廠的類，增長了額外的開發量。不知道你們還記不記得在書裏，寫工廠方法的那一章，在最後一段話中，給你們留下了一個伏筆——反射。

        在後面講到抽象工廠的時候，就提到了依賴注入的名詞。就拿抽象工廠來講，若是咱們須要新增一個數據庫類型，就須要在代碼中添加一條分支條件，破壞了開閉原則，這個時候依賴注入自己是沒有能力解決這個問題的，可是若是咱們利用語言支持反射機制，利用反射配置數據源，就能夠避免分支判斷的問題。

        讓咱們想一想，反射作了什麼工做，咱們工程一開始的難點出在對象最後都是須要new，實例化的，而咱們只能實例化當前已有的類，不能對將來會添加的新類作處理，因此一旦有新的類加入，咱們就必須修改代碼。可是，若是咱們有一種方法，不是經過new，而是經過類的名字來實例化對象，那麼我只須要將類的名字做爲配置項，就能夠實現不修改代碼的前提下加將來會出現的類。因此，咱們能夠絕不誇張的說，反射給了語言「預見將來」的能力，使得多態性和依賴注入的威力大增。

 

4、結束語

 

          看了一大堆資料，把之前的設計模式也翻出來研究了一番，畫畫圖，思路更加的清晰。IoC感受就像」抽象工廠+反射+配置文件「，如圖，咱們能夠把AbstractFactory做爲IoC容器，而且加入反射機制和配置文件，實現靈活配置類名。（解釋，配置文件取代ConcreFactory1和ConcreFactory2，具體用哪一個，靈活配置類名便可；反射用在AbstractFactory裏，取代分支判斷，避免了後期擴展修改代碼的弊病）

                                

 

         OK，面向對象無外乎那幾個原則，大道至簡的路，還很漫長，java的學習，纔剛剛開始，加油吧！