03_工厂

参考:http://www.runoob.com/design-pattern/factory-pattern.html
意图:定义一个创建对象的接口,让其子类自己决定实例化哪一个工厂类,工厂模式使其创建过程延迟到子类进行。

主要解决:主要解决接口选择的问题。

何时使用:我们明确地计划不同条件下创建不同实例时。

如何解决:让其子类实现工厂接口,返回的也是一个抽象的产品。

关键代码:创建过程在其子类执行。

应用实例: 1、您需要一辆汽车,可以直接从工厂里面提货,而不用去管这辆汽车是怎么做出来的,以及这个汽车里面的具体实现。 2、Hibernate 换数据库只需换方言和驱动就可以。

优点: 1、一个调用者想创建一个对象,只要知道其名称就可以了。 2、扩展性高,如果想增加一个产品,只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现,调用者只关心产品的接口。

缺点:每次增加一个产品时,都需要增加一个具体类和对象实现工厂,使得系统中类的个数成倍增加,在一定程度上增加了系统的复杂度,同时也增加了系统具体类的依赖。这并不是什么好事。

使用场景: 1、日志记录器:记录可能记录到本地硬盘、系统事件、远程服务器等,用户可以选择记录日志到什么地方。 2、数据库访问,当用户不知道最后系统采用哪一类数据库,以及数据库可能有变化时。 3、设计一个连接服务器的框架,需要三个协议,”POP3”、”IMAP”、”HTTP”,可以把这三个作为产品类,共同实现一个接口。

注意事项:作为一种创建类模式,在任何需要生成复杂对象的地方,都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式,而简单对象,特别是只需要通过 new 就可以完成创建的对象,无需使用工厂模式。如果使用工厂模式,就需要引入一个工厂类,会增加系统的复杂度。

是不是看起来复杂?其实呢?真正的工厂根本没这么多东西。。
左侧的接口shape,本质上为了体现6原则中的“依赖倒转”原则,如果我们可以确保,我们对象是单一对象,并且这个对象未来也不可能增加同类变体。那么没必要每个对象都写一个接口,死套教科书。同样右侧的接口定义基本也是本着同样思路。而真正的工厂方法是什么?就是ShapeFacitory一个实体而已。
设计模式原本就是对大型软件开发参考的,所以整体设计偏向于“理论化”,“理想化”,所有动能通过接口实现,每个接口最好完全隔离。这样的划分对于大模块划分没问题,但是对于日常小软件开发基本是负作用,带来好处不足弥补代码结构复杂度,和代码量提升引起的修改和维护的负作用(代码就是负债,代码越多出错概率越大,修改成本越高)。

真正的工厂方法代码只有这么一个案例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class ShapeFactory {

//使用 getShape 方法获取形状类型的对象
public Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
}

可以进一步简化为

1
2
3
if str.equals(xxxxx):
return new xx()
`

其他的多余部分都是为了满足“6大原则”的”政治任务”.

典型调用

1
2
3
4
5
//获取 Rectangle 的对象,并调用它的 draw 方法
Shape shape2 = shapeFactory.getShape("RECTANGLE");

//调用 Rectangle 的 draw 方法
shape2.draw();
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×