1. 程式人生 > >設計模式學習之Factory模式

設計模式學習之Factory模式

最近開始做C++方面的專案,雖然對於普通的編碼和C++的開發沒有什麼問題,但是感覺在設計方面還是比較欠缺,所以找了本設計模式的書開始學習,隨手記下來,大家也可以學習下。

引用:設計模式之於面向物件系統的設計和開發的作用就如同資料結構之於面向過程開發的作用一般,面向物件系統的分析和設計實際上追求的就兩點:一是高內聚,二是低耦合。這也是軟體設計所追求的,因此無論是OO中的封裝、多型、繼承,還是設計模式的原則和例項都是為這個目標努力的。在面向物件的設計和開發中,我們會用到封裝、多型、繼承、面向介面程式設計、優先使用組合而不是繼承、將抽象和實現分離的思想等,在設計模式中也能看到這些的影子,特別是組合(委託)和繼承的差異帶來系統在耦合性上的差別,在設計模式中會涉及。

在面向物件系統設計中經常遇到以下兩個問題:1.為了提高內聚和鬆耦合,經常會遇到抽象出公共介面以形成抽象基類或者介面,可以通過宣告指向基類的指標來指向實際的子類達到多型,在N多子類時,不得不在用到子類的地方編寫諸如new XXX的程式碼,帶來了2個問題,1是客戶程式設計師必須知道實際子類的名稱,2是程式的擴充套件性和維護性變得越來越困難;2.父類中並不知道具體要例項化哪一個具體的子類;這樣就引出了Factory模式的2個最重要的功能:

1、定義建立物件的介面,封裝了物件的建立;

2、使得具體化類的工作延遲到子類中。

通常使用Factory模式來解決上面的2個問題,在第一個問題中,我們經常就是宣告一個建立物件的介面,並封裝了物件的建立過程;Factory這裡類似於一個真正意義上的工廠;第二個問題中,需要提供一個物件建立物件的介面,並在子類中提供其具體實現;

這種情況在系統研發中經常用到,但這並不是Factory模式的最大威力;Factory模式不單是提供了建立物件的介面其,其最重要的是延遲了子類的例項化;

上圖中的Factory並不是只是為了封裝物件的建立,而是要把物件的建立放到子類中實現;Factory中只是提供了物件建立的介面,其實現將放在Factory的子類ConcreteFactory中進行。

Factory模式同時帶來2個問題:

1.如果每一個具體的ConcreteProduct類的例項化提供一個函式體,那麼可能不得不在系統中新增一個方法來處理新建的ConcreteProduct,這樣Factory的介面就無法封閉;當然我們可以通過建立一個Factory的子類通過多型來實現,但是也是以新建類為代價的;

2.在實現中通過引數化工廠方法,即給FactoryMethod()傳遞一個引數用於決定建立哪個具體的Product;

可以看出Factory對於物件的建立給予開發人員提供了良好的實現策略,但是Factory模式僅僅侷限於一類類,如果需要為不同的類提供一個物件建立介面,那就需要用到AbstractFactory模式了。