包你懂設計模式之 工廠方法模式

2021-10-09 04:45:43 字數 1661 閱讀 6641

在之前的部落格中我介紹了簡單工廠這個設計模式,今天我們需要裡面的內容作為基礎來講解工廠方法模式,沒有看到這邊文章的小夥伴請戳:簡單工廠模式

通過上面的準備知識,我們了解了簡單工廠是如何實現的,我們現在來分析一下。我們在客戶端想要得到乙個操作的例項時,需要呼叫 calculatefactory 類中的 getcalculate() 方法,並且傳遞乙個引數告訴工廠類我們需要例項化哪個具體操作,這樣工廠類就會幫我們建立出來。這樣做的好處在於客戶端不在關注例項建立的具體細節,就能拿到對應例項。工廠類**:

public static class calculatefactory

return calculate;}}

但是我們看到工廠類裡面的**是很雜亂的,能做很多事情:能建立減法例項、加法例項等等,它違背了設計模式的基本原則之單一職責原則(單一職責:如果乙個類有多於乙個的動機被改變,那麼這個類就具有多於乙個的職責。而單一職責原則就是指乙個類或者模組應該有且只有乙個改變的原因。)。並且我們如果要增加乙個新的運算的話,我們還是得修改**,為switch語句增加乙個分支,很顯然這又違背了開閉原則(開閉原則:對修改關閉,對拓展開放),因為每一次修改**都可能會對原先的**產生影響,使得原先的**不可靠,需要重新測試。

而工廠方法模式針對此做了點公升級,其實很簡單很粗暴,就是把工廠拆開,加減乘除四個運算,我們就拆成四個工廠唄。比如加法/減法工廠的**時下面這個:

其他的幾個操作也是這樣寫,相當於就是把原想的工廠類拆成四個單獨的類,最後我們在使用這些類的時候,用下面的方法來寫: 

我們可以對上面的**進行進一步的抽象,我們能看到所有的工廠方法都具有相似的邏輯,我們可以抽象出乙個介面出來,然後後面新加的工廠都實現這個介面,同時我們原有的四個操作都實現了  operation 類 , 所以**可以重構成下面這樣:

總結:

可以看出來,工廠方法模式可以通過簡單工廠改進而來,但是我們也可以明顯的感覺的它貌似沒有簡單工廠簡潔,同樣的功能實現**更多,而且類的數量也多。

儘管這樣,好處也是顯而易見的。當我們要新增一種運算的時候,我們需要做的時新增乙個運算類,然後新增乙個針對這個運算的工廠,我們用拓展實現,而不是修改,這樣就避免了修改**出現bug的情況。而且實際開發的時候某些物件的建立不時new一下就行的,可能還需要一些引數,一些邏輯,我們用工廠方法就可以把這些邏輯隔離開,不會像簡單工廠一樣都合併在乙個方法中,增加了**的複雜度。

這篇寫的比較匆忙也比較雜亂,但總結起來就幾句話,就是在簡單工廠的基礎上進一步抽象和推廣,把原先工廠方法進行拆分,每乙個物件對應乙個工廠。它保持了簡單工廠的優點,也克服了缺點,當然**量也加多了點,這是為數不多的缺點之一。

再進一步,幾分鐘了解抽象工廠模式  ==》 抽象工廠模式

設計模式 工廠模式之工廠方法模式

工廠方法模式是指定義乙個建立物件的介面,然後實現這個介面的工廠來決定建立什麼樣的例項。工廠方法讓類的例項推遲到子類中進行。在這個模式中,只關心需要建立的是什麼工廠,不需要關心建立的細節。而且新加入的產品符合開閉原則。1 建立支付介面,裡面定義抽象的支付方法。package com.gupao.vip...

設計模式之工廠方法模式

package com.csair.design.pattern 工廠方法,有抽象基類,每個子類生產乙個具體物件,與抽象工廠的關係是,抽象工廠生產多個產品 產品有某種內在聯絡 工廠方法只生產乙個物件 author ppt public class factorymethod public stati...

設計模式之工廠方法模式

在介紹工廠方法模式之前,先來介紹一下簡單工廠。什麼是簡單工廠?在類中,難免要例項化一些類,那麼我們把這些類的例項化抽離出來封裝成乙個工廠類,工廠類提供乙個公共的靜態或非靜態的方法來返回其他物件所需要的物件。這樣做的目的就是將物件的例項化與邏輯 分開,提高 的復用能力。這就是簡單工廠。public a...