前言:這段時間在學習設計模式,本人也是小菜一枚(因此寫的若是有錯誤的地方請大大們給予指出)。這個東西也是我一直想學習的,從點點滴滴作起,記錄下本身天天的領悟!java
1、工廠模式的動機設計模式
- 在軟件系統中,常常面臨着「某個對象」的建立工做;因爲需求的變化,這個對象常常面臨着劇烈的變化,可是它卻擁有比較穩定的接口。
- 如何應對這種變化?如何提供一種「封裝機制」來隔離出「這個易變對象」的變化,從而保持系統中「其餘依賴該對象的對象」不隨着需求改變而改變?
2、不一樣的工廠模式ide
- 簡單工廠
- 工廠方法模式
- 抽象工廠
注:簡單工廠:一個具體工廠經過條件語句建立多個產品,產品的建立邏輯集中與一個工廠類。客戶端經過傳不一樣的參數給工廠,實現建立不一樣產品的目的增長新產品時,須要修改工廠類、增長產品類,不符合OCP原則。學習
工廠方法:一個工廠建立一個產品,全部的具體工廠繼承自一個抽象工廠。客戶端先建立不一樣產品的工廠,再由工廠建立具體產品,產品的建立邏輯分散在每一個具體工廠類中。客戶端只依賴於抽象工廠與抽象產品,不依賴任何具體的工廠與具體產品增長新產品時,須要增長工廠類和產品類,符合OCP原則。優化
抽象工廠:一個具體工廠建立一個產品族,一個產品族是不一樣系列產品的組合,產品的建立的邏輯分在在每一個具體工廠類中。全部的具體工廠繼承自同一個抽象工廠。客戶端建立不一樣產品族的工廠,產品族的工廠建立具體的產品對客戶端是不可見的。增長新的產品族時,須要增長具體工廠類,符合OCP原則。增長新產品時,須要修改具體工廠類和增長產品類,不符合OCP原則。若是沒有應對「多系列對象建立」的需求變化,則沒有必要使用抽象工廠模式,這時候使用簡單的靜態工廠徹底能夠。spa
3、簡單工廠模式設計
- 解釋:簡單工廠模式是建立型模式,用於對象的建立,它不屬於23種gof設計模式。它是工廠模式家族中最簡單實用的模式,能夠理解爲是不一樣工廠模式的一個特殊實現。
- 簡單工廠模式的結構:
模式的結構中包括的角色:抽象產品(Product) code
具體產品(ConcreteProduct) 對象
構造者(Creator)blog
4、代碼演示
這裏我用的是一個這樣的例子:用一個工廠來生產出不一樣類型的窗體(記住爲同類產品)
一、在工廠模式中咱們首先考慮的應該是產品,由於產品爲窗體,因此咱們抽象出的產品父類(即抽象產品Product)是全部窗體產品都有的特性 命名爲Window.java對應的代碼:
package com.java; /** * 抽象的窗體類 * * @author zhang * */ public abstract class Window { // 抽象的方法 public abstract void funct(); }
二、父級的產品寫完之後就是考慮不一樣型號的同類(具體產品ConcreteProduct)產品了分別爲WindowBig.java和WindowSmall.java
WindowBig.java對應的代碼:
package com.java; /** * 具體產品的類(大窗體) * @author zhang * */ public class WindowBig extends Window { @Override public void funct() { System.out.println("大窗體建立成功"); } }
WindowSmall.java對應的代碼:
package com.java; /** * 具體產品類(小窗體) * @author zhang * */ public class WindowSmall extends Window { @Override public void funct() { System.out.println("小窗體建立成功"); } }
三、當產品寫完後就應該是對就的生產產品的工廠類(構造者Creator)了Factory.java
package com.java; /** * 生產產品的工廠類 * * @author zhang * */ public class Factory { // 建立窗體的方法 public Window CreateWidow(String type) { if ("big".equals(type)) { return new WindowBig(); } else if ("small".equals(type)) { return new WindowSmall(); } else { return new WindowBig(); } } }注:簡單工廠最重要的就是Create方法,根據傳入的字符來生產不一樣的對象(利用java的多態來實現)。
5、簡單工廠模式優缺點
優勢:簡單工廠模式主要用於隔離類對象的使用者和具體類型之間的耦合關係。面對一個常常變化的具體類型,緊耦合關係會致使軟件的脆弱。經過使用工廠類,外界能夠從直接建立具體產品對象的尷尬局面擺脫出來,僅僅須要負責「消費」對象就能夠了。而沒必要管這些對象究竟如何建立及如何組織的.明確了各自的職責和權利,有利於整個軟件體系結構的優化。
缺點:因爲工廠類集中了全部實例的建立邏輯,違反了高內聚責任分配原則,將所有建立邏輯集中到了一個工廠類中;它所能建立的類只能是事先考慮到的,若是須要添加新的類,則就須要改變工廠類了。
適合應用的場景:
- 工廠類負責建立的對象比較少
- 客戶只知道傳入工廠類的參數,對於如何建立對象(邏輯)不關心
- 因爲簡單工廠很容易違反高內聚責任分配原則,所以通常只在很簡單的狀況下應用