我们实例化对象的时候,一般会使用new来创建,而工厂模式,是用来替代new的一种模式。
在以前,小明同学的厨艺不错,于是他想去开一家餐馆,由于前期资金不足(创业前期嘛),请不起厨师,所以他只请了一个服务员,然后炒菜就是自己来做了,他每天需要做的工作就是:
1、客人来了点餐
2、服务员把客人点的才给小明,小明去厨房做菜。
3、菜做好后端给客人
因为他需要自己亲自下厨,所以他需要对每个菜的做法都了然于心(类的初始化工作很多)。例如这其中一道中国菜是这样做的,还好小明的记忆力比较强,这么多步骤都让他记下了。
public class ChineseFood1 extends Food{ public ChineseFood1(String 调味料1, String 材料2, .....){ //下油 //煎炒 //........ } }
private class hello
那么问题来了,有一天小明病了,不能做菜了,那餐馆是不是就无法运营了(耦合度太高,小明不能被别人替代),又或者小明有时候记错了调味料,客人点的清淡广东菜结果给下了很多辣椒,结果客人很生气,小明蒙受了损失(容易出错)
// 正确的参数 GuangdongFood food = new GuangdongFood(油,青菜,鱼....) // 小明的做法,参数传错了 GuangdongFood food = new GuangdongFood(油,辣椒,鱼....)
后来小明一想这样不行,我要记那么多菜的做法得累死,还容易出错,于是他招了两个厨师回来组成一个厨房(组成工厂)。于是小明现在的工作变成了这样
1、客人来了点餐
2、服务员把客人点的餐给小明,小明跟厨师说我要这个菜
3、厨师把菜做好后小明端给客人
现在好了,小明现在不用自己做菜了,再也不用记那么多做菜的步骤了(不需要知道每个类实例化的过程),小明只需要跟厨房那边说一声我要什么,厨房就给自己生成什么。小明病了的话,也只需要找人过来顶替一下就可以了(耦合性降低)。
// 做菜的工厂 public class FoodFactory { public static Food getInstance(String food){ Food foods = null; if (food.equals("JapenFood")){ return new JapenFood(); }else if (food.equals("ChineseFood")){ return new ChineseFood(); }else{ return null; } } }
// 小明获取中国菜1 Food chineseFood1 = FoodFactory.getInstance("中国菜1");
还是上面的那个例子,小明的餐馆越开越大,为了提高竞争了,餐馆的菜谱上除了原来的中国菜和日本菜,还添加了韩国菜,印度菜......等等,但是这么多的菜系,厨房里的厨师也表示忙不过来了(一个工厂无法创建所有的类,太多了)。
于是小明为了减轻厨房的压力,再建了几个厨房来处理特定的菜系。
//将工厂抽象出来 public abstract class FoodFactory { public abstract Food getInstance(); } //日本菜工厂 public class JapenFoodFactory extends FoodFactory{ @Override public Food getInstance() { ......... return new JapenFood(); } } //中国菜工厂 public class ChineseFactory extends FoodFactory{ @Override public Food getInstance() { ......... return new ChineseFood(); } }
这时候小明拿一道日本菜的步骤变为
//先实例化日本菜工厂 Factory factory = new JapenFactory(); //工厂里面拿菜 Food food = factory.getInstance();
抽象工厂模式和工厂方法模式的区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。
小明为了给自己的餐馆提升竞争力,特意推出了送饮料活动。
我们都知道,吃饭的时候,饮料的搭配是很重要的。所以小明特地地选出了下面的搭配。
1、中国菜配汤
2、日本菜配酒
.........
要满足上面的要求,就可以使用抽象工厂了。