《設計模式》工廠家族

來源:互聯網
上載者:User

標籤:style   class   blog   http   ext   使用   

    設計模式被分成了三種類型,這次來說一下建立型中的工廠家族(簡單Factory 方法,Factory 方法模式,抽象工廠)。通過瞭解,三者之間的比較來加深對工廠家族的瞭解。

簡單工廠:
    工廠類中有必要的邏輯推斷,依據client的選擇能夠動態執行個體化相關類.去除了與詳細產品的依賴。

    例:

           

    在上述計算機的範例結構圖中,假設我們要新加一個功能,不僅要添加預算類的子類,且還要改動運算類工廠,添加switch的case分之條件,這也就違背了開放封閉原則。

    所謂的開放封閉原則:就是(軟體實體類,模組,函數等)對擴充開放,改動封閉。

    缺點:不符合開閉原則

Factory 方法:    定義一個用於建立對象的介面,讓子類決定執行個體化哪個類.使得一個類的執行個體化延遲到其子類。

    例:

                  

       

    是計算機的Factory 方法結構圖,當須要添加新的功能的時候,僅僅須要對應添加功能的運算類和工廠類,而不須要去改動原有的工廠類。

    缺點:添加一個類,須要添加額外的開發量

    長處:僅僅有擴充變化,沒有改動變化。克服了開閉原則。


簡單工廠VSFactory 方法:    Factory 方法把簡單工廠內部邏輯推斷移到了client代碼來進行.之前添加功能須要改動原有工廠類,如今僅僅需改動client。   

    兩者都是集中封裝了對象的建立,使得更換對象不須要做大的修改就可實現,減少了耦合性。
             
抽象工廠:

     提供建立一系列相關或互相依賴對象的介面,而無需指定他們詳細的類。

     結構圖:

       

        

    缺點:若要添加新功能,就要添加三個類,還要改動原有類。

    長處:符合開放封閉,依賴倒轉原則。 

          易於交換產品系列;詳細的建立執行個體過程和client分離,client是通過抽象介面操縱執行個體,產品的詳細類名也被詳細工廠的實現分離,不會出如今客戶代碼中。 


    每一個模式都有自己的優缺點,怎樣解決所用模式的缺點呢,這裡提到一個反射技術:

    格式:Assembly.Load("程式集名稱").createInstance("命名空間.類名稱")


    對於反射個人不是非常理解,這裡借用查到的資料來解釋一下反射。  所謂反射就是依據程式設計語言提供的反射類,直接將字串轉化為類或方法,然後再進行調用。這樣一來,在抽象原廠模式中,程式猿在client代碼中能夠不知道詳細的類名,通過反射來將輸入或者擷取到的字串轉化為抽象原廠模式中的工廠類,再調用同名方法執行個體化產品類,這樣一來就能夠全然避免使用邏輯推斷了。

    使用反射能夠彌補抽象工廠的不足。


Factory 方法VS抽象工廠:抽象原廠模式改變了抽象工廠介面的結構。在Factory 方法模式中,工廠類的方法僅僅能執行個體化一種產品類; 可是在抽象原廠模式中,抽象工廠介面包括了多個抽象方法,這些方法能夠執行個體化不同的產品類。

      

      

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.