前面幾篇,我們已經把簡單工廠、工廠方法模式以及抽象工廠模式一一進行了拆解,一步步讓我們學會了這幾個工廠模式,哦,對了,簡單工廠並不算真正意義上的工廠。 我們通過吃披薩的啟發,對創建披薩進行了改造;又發展了遠景,對披薩加盟有了濃厚的興趣,並開了很多加盟店;又對材料進行了嚴格把控,才有了現在的規模。工廠 ...
前面幾篇,我們已經把簡單工廠、工廠方法模式以及抽象工廠模式一一進行了拆解,一步步讓我們學會了這幾個工廠模式,哦,對了,簡單工廠並不算真正意義上的工廠。
我們通過吃披薩的啟發,對創建披薩進行了改造;又發展了遠景,對披薩加盟有了濃厚的興趣,並開了很多加盟店;又對材料進行了嚴格把控,才有了現在的規模。工廠模式,就這樣一層層地展現在我們面前。
首先,來看下上次遺留的抽象工廠模式的問題。抽象工廠允許客戶使用抽象的介面來創建一組相關的產品,而不需要知道(或關心)實際產出的具體產品是什麼。這樣一來,客戶就從具體的產品中被解耦。讓我們看看類圖來瞭解其中的關係。
這是一張相當複雜的類圖:讓我們從PizzaStore的觀點來看一看它:
工廠方法是不是潛伏在抽象工廠裡面?
我們註意到,抽象工廠的每個方法實際上看起來都像工廠方法。每個方法能被聲明稱抽象,而子類的方法覆蓋這些方法來創建某些對象。
所以,抽象工廠方法經常以工廠方法的方式實現,這很有道理,對吧?抽象工廠的任務是定一個負責創建一組產品的介面。這個介面內的每個方法負責創建一個具體產品,同時我們利用實現抽象工廠的子類來提供這些具體的做法。所以,在抽象工廠中利用工廠方法實現生產方法是相當自然的做法。
比較工廠方法和抽象工廠
因為書中用圖描繪了對比的關係,小編力求同書本結合,故在此把書本中的類圖貼出來,大家不要介意了。
設計箱內的工具
還是按照之前的套路,總結下工具箱內新增的工具吧
OO基礎
抽象、封裝、繼承、多態
OO原則
封裝變化
多用組合,少用繼承
針對介面編程,不針對實現編程
為交互對象之間的松耦合設計而努力
依賴抽象,不要依賴具體類(我們有了一個新原則,知道我們儘可能地讓事情保持抽象)
OO模式
『策略模式』、『觀察者模式』、『裝飾者模式』
『抽象工廠模式』提供一個介面,用於創建相關或依賴對象的家族,而不需要明確指定具體類
『工廠方法模式』定義了一個創建對象的介面,但由子類決定要實例化的類是哪一個。工廠方法讓類把實例化推遲到子類
結尾
很高興,聽過這麼多的篇幅,大家能和我堅持學完。小編知道,針對這個工廠模式,寫的不那麼盡如人意。篇幅太多,描述不清,可能小編自己的想法加的也不夠多,被書本牽著鼻子走了。
所以,針對工廠模式,包括後面更多的模式,小編還是會做下改變。之前說過小編會先總體理解一遍再進行編寫,以後可能小編還得列一個大綱先,然後和大家一起學習,一起進步。
小編希望能看到更多的意見和建議,讓這個系列寫的更好。謝謝大家的支持