簡單工廠不是一種設計模式,反而比較像是一種程式設計習慣
結構簡單工廠包含如下角色:
現在使用簡單工廠對上面案例進行改進,類圖如下:
* @description: 咖啡類
* @author: dym
*/public abstract class coffee
//加奶
public void addmilk()
}
package com.itheima.pattern.factory.******_factory;
/** * @version v1.0
* @classname: americancoffee
* @description: 沒事咖啡
* @author: dym
*/public class americancoffee extends coffee
}
package com.itheima.pattern.factory.******_factory;
/** * @version v1.0
* @classname: lattecoffee
* @description: 拿鐵咖啡
* @author: dym
*/public class lattecoffee extends coffee
}
package com.itheima.pattern.factory.******_factory;
/** * @version v1.0
* @classname: ******coffeefactory
* @description: 簡單咖啡工廠類,用來生產咖啡
* @author: dym
*/public class ******coffeefactory else if("latte".equals(type)) else
return coffee;}}
package com.itheima.pattern.factory.******_factory;
/** * @version v1.0
* @classname: coffeestore
* @description: todo(一句話描述該類的功能)
* @author: dym
*/public class coffeestore
}
package com.itheima.pattern.factory.******_factory;
/** * @version v1.0
* @classname: client
* @description: todo(一句話描述該類的功能)
工廠(factory)處理建立物件的細節,一旦有了******coffeefactory,
coffeestore類中的ordercoffee()就變成此物件的客戶,後期如果需要coffee物件直接從工廠中獲取即可。
這樣也就解除了和coffee實現類的耦合,同時又產生了新的耦合,
coffeestore物件和******coffeefactory工廠物件的耦合,工廠物件和商品物件的耦合。
後期如果再加新品種的咖啡,勢必要需求修改******coffeefactory的**,違反了開閉原則。
工廠類的客戶端可能有很多,比如建立美團外賣等,這樣只需要修改工廠類的**,省去其他的修改操作。
優點:
封裝了建立物件的過程,可以通過引數直接獲取物件。
把物件的建立和業務邏輯層分開,這樣以後就避免了修改客戶**,
如果要實現新產品直接修改工廠類,而不需要在原**中修改,這樣就降低了客戶**修改的可能性,更加容易擴充套件。
缺點:
增加新產品時還是需要修改工廠類的**,違背了「開閉原則」。
工廠模式 簡單工廠
簡單工廠其實並不是乙個設計模式,反而比較像一種程式設計習慣。我個人的這樣總結簡單工廠 建立乙個類,封裝建立物件的 故事 現在我要開一家披薩店,叫bbk 必敗客 披薩,賣很多種披薩 芝士披薩 榴蓮披薩等等,我有乙個orderpizza string type 方法,根據客戶傳來的type來提供不同的披...
工廠模式 簡單工廠
工廠 處理建立物件的細節。目的 將例項化具體類的 從應用中抽離,或者封裝起來,可以避免干擾應用的其他部分。簡單工廠 簡單工廠其實不是乙個設計模式,反而像一種程式設計習慣。產品實現 desc 產品a public inte ce a class a1 implements a override pub...
簡單工廠模式,工廠模式,抽象工廠模式
三種模式看了一天,記錄下自己的理解 headfirst,比薩店為例 1,簡單工廠模式 乙個具體的工廠類 pizzafactory 乙個抽象的產品類pizza,可以派生出多個具體的產品類 客戶 pizzastore類 工廠類 pizzafactory類關聯產品類pizza,工廠生產出不同型別的pizz...