工廠方法模式與IoC/DI控制反轉和依賴注入


 IoC——Inversion of Control  控制反轉
 DI——Dependency Injection   依賴注入


        要想理解上面兩個概念,就必須搞清楚如下的問題:

  • 參與者都有誰?
  • 依賴:誰依賴於誰?為什么需要依賴? 
  • 注入:誰注入於誰?到底注入什么?
  • 控制反轉:誰控制誰?控制什么?為何叫反轉(有反轉就應該有正轉了)?
  • 依賴注入和控制反轉是同一概念嗎?

        下面就來簡要的回答一下上述問題,把這些問題搞明白了,IoC/DI也就明白了。
(1)參與者都有誰:

        一般有三方參與者,一個是某個對象;一個是IoC/DI的容器;另一個是某個對象的外部資源。
        又要名詞解釋一下,某個對象指的就是任意的、普通的Java對象; IoC/DI的容器簡單點說就是指用來實現IoC/DI功能的一個框架程序;對象的外部資源指的就是對象需要的,但是是從對象外部獲取的,都統稱資源,比 如:對象需要的其它對象、或者是對象需要的文件資源等等。


(2)誰依賴於誰:

        當然是某個對象依賴於IoC/DI的容器


(3)為什么需要依賴:

        對象需要IoC/DI的容器來提供對象需要的外部資源


(4)誰注入於誰:

        很明顯是IoC/DI的容器 注入 某個對象


(5)到底注入什么:

        就是注入某個對象所需要的外部資源


(6)誰控制誰:

        當然是IoC/DI的容器來控制對象了


(7)控制什么:

        主要是控制對象實例的創建


(8)為何叫反轉:

        反轉是相對於正向而言的,那么什么算是正向的呢?考慮一下常規情況下的應用程序,如果要在A里面使用C,你會怎么做呢?當然是直接去創建C的對象,也就是 說,是在A類中主動去獲取所需要的外部資源C,這種情況被稱為正向的。那么什么是反向呢?就是A類不再主動去獲取C,而是被動等待,等待IoC/DI的容 器獲取一個C的實例,然后反向的注入到A類中。
 

        用圖例來說明一下,先看沒有IoC/DI的時候,常規的A類使用C類的示意圖,如圖7所示:



                                      圖7  常規A使用C示意圖

當有了IoC/DI的容器后,A類不再主動去創建C了,如圖8所示:



                                     圖8  A類不再主動創建C


而是被動等待,等待IoC/DI的容器獲取一個C的實例,然后反向的注入到A類中,如圖9所示:


                                               圖9  有IoC/DI容器后程序結構示意圖


(9)依賴注入和控制反轉是同一概念嗎?


        根據上面的講述,應該能看出來,依賴注入和控制反轉是對同一件事情的不同描述,從某個方面講,就是它們描述的角度不同。依賴注入是從應用程序的角度在描述,可以把依賴注入描述完整點:應用程序依賴容器創建並注入它所需要的外部資源;而控制反轉是從容器的角度在描述,描述完整點:容器控制應用程序,由容器反向的向應用程序注入應用程序所需要的外部資源。


(10)小結一下:

        其實IoC/DI對編程帶來的最大改變不是從代碼上,而是從思想上,發生了“主從換位”的變化。應用程序原本是老大,要獲取什么資源都是主動出擊,但是在 IoC/DI思想中,應用程序就變成被動的了,被動的等待IoC/DI容器來創建並注入它所需要的資源了。
        這么小小的一個改變其實是編程思想的一個大進步,這樣就有效的分離了對象和它所需要的外部資源,使得它們松散耦合,有利於功能復用,更重要的是使得程序的整個體系結構變得非常靈活。

2:工廠方法模式和IoC/DI有什么關系呢?


        從某個角度講,它們的思想很類似。
        上面講了,有了IoC/DI過后,應用程序就不再主動了,而是被動等待由容器來注入資源,那么在編寫代碼的時候,一旦要用到外部資源,就會開一個窗口,讓 容器能注入進來,也就是提供給容器使用的注入的途徑,當然這不是我們的重點,就不去細細講了,用setter注入來示例一下,看看使用IoC/DI的代碼 是什么樣子,示例代碼如下:

 

 

public class A {

    /**

     * 等待被注入進來

     */

    private C c = null;

    /**

     * 注入資源C的方法

     * @param c 被注入的資源

     */

    public void setC(C c){

       this.c = c;

    }

    public void t1(){

       //這里需要使用C,可是又不讓主動去創建C了,怎么辦?

       //反正就要求從外部注入,這樣更省心,

       //自己不用管怎么獲取C,直接使用就好了

       c.tc();

    }

}

接口C的示例代碼如下:

 

 

public interface C {

    public void tc();

}

 

        從上面的示例代碼可以看出,現在在A里面寫代碼的時候,凡是碰到了需要外部資源,那么就提供注入的途徑,要求從外部注入,自己只管使用這些對象。
        再來看看工廠方法模式,如何實現上面同樣的功能,為了區分,分別取名為A1和C1。這個時候在A1里面要使用C1對象,也不是由A1主動去獲取C1對象, 而是創建一個工廠方法,就類似於一個注入的途徑;然后由子類,假設叫A2吧,由A2來獲取C1對象,在調用的時候,替換掉A1的相應方法,相當於反向注入 回到A1里面,示例代碼如下:

 

 

public abstract class A1 {

    /**

     * 工廠方法,創建C1,類似於從子類注入進來的途徑

     * @return C1的對象實例

     */

    protected abstract C1 createC1();

    public void t1(){

       //這里需要使用C1類,可是不知道究竟是用哪一個

//也就不主動去創建C1了,怎么辦?

       //反正會在子類里面實現,這里不用管怎么獲取C1,直接使用就好了

       createC1().tc();

    }

}

子類的示例代碼如下:

 

 

public class A2 extends A1 {

    protected C1 createC1() {

       //真正的選擇具體實現,並創建對象

       return new C2();

    }

}

 

        C1接口和前面C接口是一樣的,C2這個實現類也是空的,只是演示一下,因此就不去展示它們的代碼了。
        仔細體會上面的示例,對比它們的實現,尤其是從思想層面上,會發現工廠方法模式和IoC/DI的思想是相似的,都是“主動變被動”,進行了“主從換位”,從而獲得了更靈活的程序結構。

轉載:

http://baitai.iteye.com/blog/792980

http://www.iteye.com/topic/692793


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM