工廠模式的好處就在於將工廠和產品之間的耦合下降,將具體產品的構造過程放在了具體工廠類裏面。在之後擴展產品的時候方便不少,只須要添加一個工廠類,一個產品類,就能方便的添加產品,而不須要修改原有的代碼。而在簡單工廠中,若是要增長一個產品,則須要修改工廠類,增長if/else分支,或者增長一個case分支,工廠模式符合軟件開發中的OCP原則(open close principle),對擴展開放,對修改關閉。
抽象工廠模式:這個模式我老是感受和builder模式很是類似。
工廠方法模式提供的是對一個產品的等級模式,而抽象工廠方法提供的是對多個產品的等級模式,注意,這裏的多個具體產品之間是相互耦合的,也就是說這裏的抽象工廠提供的產品之間是存在某種聯繫的。
有人作以下的比較:
工廠方法模式:一個抽象產品類,能夠派生出多個具體產品類。
一個抽象工廠類,能夠派生出多個具體工廠類。
每一個具體工廠類只能建立一個具體產品類的實例。
抽象工廠模式:多個抽象產品類,每一個抽象產品類能夠派生出多個具體產品類。
一個抽象工廠類,能夠派生出多個具體工廠類。
每一個具體工廠類能夠建立多個具體產品類的實例。
區別:工廠方法模式只有一個抽象產品類,而抽象工廠模式有多個。
工廠方法模式的具體工廠類只能建立一個具體產品類的實例,而抽象工廠模式能夠建立多個。
下面是一個形象的比喻:
不管是簡單工廠模式、工廠模式仍是抽象工廠模式,它們本質上都是將不變的部分提取出來,將可變的部分留做接口,以達到最大程度上的複用。拿一個生產水杯(cup)的工廠舉例:起初,不用工廠模式,我必須在生產水杯以前知道水杯的材料和形狀等水杯的全部特徵才能生產,這就是咱們的new Cup();這個Cup必須是具體的。廠主發現同一形狀的被子,只是材料不一樣,如一個是玻璃(glass)的,一個是瓷(china)的,可是確要兩條生產線,顯然有資源浪費的嫌疑。如今廠主生產杯子時先不讓生產線知道我要產的是玻璃的仍是瓷的,而是讓它在不知道具體材料的狀況下先作它能作的,等到它把模具作好,只須要向其中填充玻璃原料或者瓷原料就能夠造出同一形狀的具體杯子了。可是很惋惜,java並不能new一個抽象的Cup,因此就有了簡單工廠模式。原來是Cup cup=new Cup;如今是SimpleCupFactory.createCup(String cupName),根據cup的名字生產Cup,而createCup返回的是一個實現了 Cup接口或抽象類的具體Cup。簡單抽象工廠模式有一個問題,就是當我如今想生產一個一樣形狀的鐵杯時,工廠裏並無定義相應的處理流程,只能更改createCup方法,這就不合理了。我如今只是想生產鐵杯,你只要在最後的時候把玻璃原料換成鐵的不就好了嗎,幹嗎還要更改整條生產線呢?因而就有了工廠模式。原來生產線在生產模具的時候還要考慮是爲玻璃杯生產的模具仍是爲鐵杯生產的模具,如今它不用管了。CupFactory.createCup()建立Cup.CupFactory是接口或抽象類。實現它的具體子類會建立符合Cup接口的具體Cup。那麼如今廠主想要生產水壺(kettle),用工廠模式就不得再也不造一條水壺生產線,能不能在水杯生產線同時生產水壺呢?這就是抽象工廠模式。
java