设计模式入门学习之工厂模式(工厂方法模式)
关键字: 设计模式当看到"new",就会想到"具体","new"有什么不对劲的?
在技术上,new没有错,毕竟这是java的基础部分.针对接口编程,可以隔离掉以后系统可能发生的一大堆改变.为什么呢?如果代码是针对接口而写,你们通过多态,它可以与任何新类实现该接口.但是,当代码使用大量的具体类时,等于是自找麻烦,因为一但加入新的具体类就必须改变代码,也就是说你的代码并非"对修改关闭".别忘了,我们的第一个原则用来处理改变,"找出会变化的方面,把它们从不变的部分分离出来".
假设你有个披萨店,你的代码可能这么写:
pizza orderPizza(){
Pizza piz = new Pizza();
//为了让系统有弹性,我们很希望这是一个抽象类或接口,但如果这样,这些类或接口就无法直接实例化
piz.prepare();
piz.bake();
piz.cut();
piz.box();
return piz;
}
但是你需要更多的披萨类型,所以必须增加一些代码,来决定适合的披萨类型,然后再制造这个披萨:
pizza orderPizza(String type){
//现在把披萨类型传入orderPizza
Pizza piz;
//根据披萨的类型,实例化正确的具体类,注意这里的任何披萨都必须实现Pizza接口
if(type.equals("cheese")){
piz = new CheesePizza();
}else if(type.equals("greek")){
piz = new GreekPizza();
}
//某一天你为了赶上竞争者,你加入了一些流行风味的披萨,greek披萨卖的不好,你要从菜单去掉,随着时间的过去,这里就必须一改再改
else if(type.equals("clam")){
piz = new ClamPizza();
}
else if(type.equals("veggie")){
piz = new VeggaePizza();
}
//一旦我们有了一个披萨,需要做一些准备,然后烘烤.切片.装盒,这里是我们不想改变的地方
piz.prepare();
piz.bake();
piz.cut();
piz.box();
return piz;
}现在我们知道哪些会改变哪些不会改变,该是使用封装的时候了,现在我们把创建对象的代码抽离,建立一个简单披萨工厂,这个工厂只管如何创建披萨:
public class SimplePizzaFactory {
//内定一个createPizza()方法,所有客户通过这个方法来实例化新对象
public Pizza createPizza(String type) {
Pizza pizza = null;
//移植过来的代码,基本没什么变动
if (type.equals("cheese")) {
pizza = new CheesePizza();
} else if (type.equals("pepperoni")) {
pizza = new PepperoniPizza();
} else if (type.equals("clam")) {
pizza = new ClamPizza();
} else if (type.equals("veggie")) {
pizza = new VeggiePizza();
}
return pizza;
}
}
这么做有什么好处?似乎只是把问题搬到另一个对象罢了,问题依然存在.
别忘了,SimplePizzaFactory可以有很多客户,虽然目前只看到orderPizza()方法是它的客户,然而可能还有其他的客户.所以把创建披萨的代码包装进一个类,当以后实现改变时,只需修改这个类即可.别忘了,我们正要把具体实例化过程从客户的代码中删除.
修改客户代码,重做PizzaStore类:
public class PizzaStore {
//加一个SimplePizzaFactory的引用
SimplePizzaFactory factory;
public PizzaStore(SimplePizzaFactory factory) {
this.factory = factory;
}
public Pizza orderPizza(String type) {
Pizza pizza;
//而orderPizza()方法通过简单传入订单类型来使用工厂创建披萨,
//请注意,我们把new操作符替换成工厂对象的创建方法,这里不在使用具体实例化
pizza = factory.createPizza(type);
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
return pizza;
}
//...other methon
}简单工厂其实不是一个设计模式,反而比较像是一种编程习惯,接下来继续用披萨店来讲述工厂方法模式.
披萨店经营有成,击败了竞争者,现在大家都希望来加盟你的披萨店,身为经营者,你希望确保加盟店的营运质量,希望这些店都使用你那些经过时间考验的代码.但是区域的差异呢?每家加盟店都可能想要提供不同风味的披萨,比方说纽约.芝加哥.加州,这就受到了开店地点及该地区口味的影响.
如果利用SimplePizzaFactory,写出3种不同的工厂,分别是NYPizzaFactory,ChicagoPizzaFactory,CaliforniaPizzaFactory,那么各个加盟店都有合适的工厂可以使用,这是一种做法:
NYPizzaFactory nyFactory = new NYPizzaFactory();//这里创建的工厂是制造纽约风味的披萨
PizzaStore nyStore = new PizzaStore(nyFactory);//然后建立一个披萨店,将纽约工厂的引用作为参数
nyStore.orderPizza("Veggie"); //制造披萨,会得到纽约风味的披萨
在推广SimplePizzaFactory时,你发现加盟店的确采用你的工厂创建披萨,但是他们自创流程:烘烤的做法有些差异.不要切片.使用其他厂商的盒子.怎么让你的质量多一些质量控制多些弹性呢?
我们再来修改一些披萨店,先声明一个工厂方法:
//现在PizzaStore是抽象的,每个子类都会覆盖createPizza方法,同时使用PizzaStore定义的orderPizza方法,
//甚至可以把orderPizza定义为tinal,以防止被之类覆盖
public abstract class PizzaStore {
/**
*现在把工厂对象移到这个方法中,工厂方法现在是抽象的,所以依赖子类来处理对象的创建
*工厂方法必须返回一个产品,超类中定义的方法,通常使用到工厂方法的返回值
*工厂方法将客户(如orderPizza)和实际创建具体产品的代码分割开来
*/
abstract Pizza createPizza(String type);
public Pizza orderPizza(String type) {
//现在createPizza()方法从工厂对象中移回PizzaStore
Pizza pizza = createPizza(type);
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
return pizza;
}
}
好了,让我们把纽约风味的加盟店开起来吧:
//createPizza()返回一个Pizza对象,由子类全权负责该实例化哪一个具体Pizza
public class NYPizzaStore extends PizzaStore {
//必须实现的createPizza方法
Pizza createPizza(String item) {
if (item.equals("cheese")) {
return new NYStyleCheesePizza();
} else if (item.equals("veggie")) {
return new NYStyleVeggiePizza();
} else if (item.equals("clam")) {
return new NYStyleClamPizza();
} else if (item.equals("pepperoni")) {
return new NYStylePepperoniPizza();
} else return null;
}
}
实现一下披萨本身,没披萨开什么加盟店呢:
//从一个抽象披萨类开始,所有的具体披萨都必须派生自这个类
public abstract class Pizza {
String name; //每个披萨都有名称,面团类型,一套佐料
String dough;
String sauce;
ArrayList toppings = new ArrayList();
void prepare() {
System.out.println("Preparing " + name);
System.out.println("Tossing dough...");
System.out.println("Adding sauce...");
System.out.println("Adding toppings: ");
//准备工作需要以特定的顺序进行
for (int i = 0; i < toppings.size(); i++) {
System.out.println(" " + toppings.get(i));
}
}
void bake() {}
void cut() {}
void box() {}
public String getName() {return name;}
public String toString() {
StringBuffer display = new StringBuffer();
display.append("---- " + name + " ----\n");
display.append(dough + "\n");
display.append(sauce + "\n");
for (int i = 0; i < toppings.size(); i++) {
display.append((String )toppings.get(i) + "\n");
}
return display.toString();
}
}
现在我们来定义纽约和芝加哥风味的具体子类,并吃些披萨怎么样:
public class NYStyleCheesePizza extends Pizza {
public NYStyleCheesePizza() {
name = "NY Style Sauce and Cheese Pizza";
dough = "Thin Crust Dough";
sauce = "Marinara Sauce";
toppings.add("Grated Reggiano Cheese");
}
}
public class ChicagoStyleCheesePizza extends Pizza {
public ChicagoStyleCheesePizza() {
name = "Chicago Style Deep Dish Cheese Pizza";
dough = "Extra Thick Crust Dough";
sauce = "Plum Tomato Sauce";
toppings.add("Shredded Mozzarella Cheese");
}
//这个芝加哥风味披萨覆盖cut()方法,将披萨切成正方形
void cut() {
System.out.println("Cutting the pizza into square slices");
}
}
public class PizzaTestDrive {
public static void main(String[] args) {
//建立2个不同的店
PizzaStore nyStore = new NYPizzaStore();
PizzaStore chicagoStore = new ChicagoPizzaStore();
//下订单
Pizza pizza = nyStore.orderPizza("cheese");
System.out.println("Ethan ordered a " + pizza.getName() + "\n");
pizza = chicagoStore.orderPizza("cheese");
System.out.println("Joel ordered a " + pizza.getName() + "\n");
}
}认识工厂方法模式的时刻终于到了,工厂方法模式定义了一个创建对象的接口,但由子类决定要实例化的类是哪个.工厂方法让类把实例化推迟到子类
评论
工厂是创建型的,
目的只是为了把new的位置改变,
也就是把生成对象的位置换一个位置,
因为你不是想让new 后面的部分动起来吗,那就把改动的抽出到其它地方.
当一个程序员OO设计多了,思考多了,设计模式习惯的出现会很自然而然,到时候才看相关的理论书籍会有会心一笑的明悟。
工厂模式是入门的模式,也是大多数模式的基础。这个不理解透彻就入不了们。这个理解错误的人,根本算不上合格的架构师。如果一个教材充满了虚拟出来的pizza之类的例子,说明什么问题?作者本身就没什么经验,所以只好胡编乱造。
接口干什么的?屏蔽细节。暴露了具体类,就依赖细节了。如果这个具体类需要修改它的行为,或者这个类废弃,那所有的代码都要改。这根本是瞎扯。还不如直接new简单省事。
非常基本的东西,讲了好几年了。。。。。
多写点代码就知道了。别老是什么Pizza、cookie的。
会就是会,不会就是不会,别拿设计模式装神圣。自己关起门瞎说没关系,放公开地方说,把初学者都误导了。
最反感这种浮夸的作风。不懂装懂,为什么不能老老实实承认自己没有多少设计经验呢?特别是有些著名专家,其实没有多少设计经验,靠名气糊弄外行。
已经有人指出楼主的代码来自HEAD FIRST DESIGN PATTERN,虽然中文部分有楼主努力,但是否应该说明这Code是引用?
Pizza createPizza(String type)可以改成
Pizza createPizza(PizzaType type);
或
Pizza createPizza(int type);
可由程序员自己另外封装确定判断生成类,用String是为了方便阅读理解。
OO解耦是思维模式,设计模式的书不是“21天学会java”,教给你的是指导思想,代码不能Copy & Paste.
工厂方法,是不应该暴露实现类的名称的。
Factory.CreateProduct("A");跟new A()相比,根本就没有区别。只不过是限制了A可以被看到的方法而已。
这样用模式,叫脱裤子放P。
工厂模式搞不清楚,后面都是白扯。不忍心见你们在错误的道路上越走越远,特地出来指点。
楼主说的一句话很好:“模式其实是一种编程习惯”,正如一个正常人在现实中会做什么一样,这些模式正是模拟了这些。当我们真正理解面向OO,并具有OO的思想以后,这些应该都不是问题。
楼主继续把其他的设计模式的见解发出来。让我们这些菜鸟能学习
抽象工厂模式 优点:对产品的增加支持OCP原则,缺点:对产品系列的增加不支持OCP原则,
PS:楼上用工厂来作新产品有点浪费....
不如用状态位来区分产品
工厂是用在方法实现上有区别的业务类中的.
楼主继续把其他的设计模式的见解发出来。让我们这些菜鸟能学习
发表评论
提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则
- 浏览: 20852 次
- 性别:

- 来自: 北京

- 详细资料
搜索本博客
我的相册
共 30 张
最近加入圈子
最新评论
-
使用iBatis的自动化代码生 ...
有没有根据类生产数据库和xml的?
-- by aninfeel -
使用iBatis的自动化代码生 ...
IBatis去除注释版 http://hugh-lin.javaeye.com/ ...
-- by hugh-lin -
使用iBatis的自动化代码生 ...
我的不能用啊,郁闷掉了,真的是很黄很暴力。
-- by horror -
搭建Cloud Computing测试 ...
to fredzhang : 呵呵,我只是说用hadoop/hbase来搭 ...
-- by blank -
搭建Cloud Computing测试 ...
1. gfs的论文你仔细阅读过了吗?它的思想决定了基于它应当如何来实现,如何才能 ...
-- by fredzhang






评论排行榜