您的位置:首页 > 其它

设计模式:工厂方法模式(Factory Method)

2016-04-14 20:48 323 查看

引子

话说十年前,有一个暴发户,他家有三辆汽车——Benz 奔驰、Bmw 宝马、Audi 奥迪,还雇了司机为他开车。不过,暴发户坐车时总是怪怪的:上Benz 车后跟司机说“开奔驰车!”,坐上Bmw 后他说“开宝马车!”,坐上Audi 说“开奥迪车!”。你一定说:这人有病!直接说开车不就行了?!而当把这个暴发户的行为放到我们程序设计中来时,会发现这是一个普遍存在的现象。幸运的是,这种有病的现象在OO(面向对象)语言中可以避免了。下面就以Java 语言为基础来引入我们本文的主题:工厂模式。

分类

工厂模式主要是为创建对象提供过渡接口,以便将创建对象的具体过程屏蔽隔离起来,达到提高灵活性的目的。

工厂模式在《Java 与模式》中分为三类:

1)简单工厂模式(Simple Factory)

2)工厂方法模式(Factory Method)

3)抽象工厂模式(Abstract Factory)

这三种模式从上到下逐步抽象,并且更具一般性。

GOF 在《设计模式》中将工厂模式分为两类:

1)工厂方法模式(Factory Method)

2)抽象工厂模式(Abstract Factory)

将简单工厂模式(Simple Factory)看为工厂方法模式的一种特例,两者归为一类。

(在这里我们使用第二种父类方法,将简单工厂模式(Simple Factory)看为工厂方法模式的一种特例)

这篇博客我们先讲解工厂方法模式,我们从讲简单工厂模式,然后引出工厂方法模式。

简单工厂模式

简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单:定义一个用于创建对象的接口。

先来看看它的组成:

1) 工厂类角色(Creator):这是本模式的核心,含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。

2) 抽象产品角色(Product):它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽象类来实现。

3) 具体产品角色(ConcreteProduct):工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。

来用类图来清晰的表示下的它们之间的关系:



那么简单工厂模式怎么来使用呢?我们就以简单工厂模式来改造暴发户坐车的方式——现在暴发户只需要坐在车里对司机说句:“开车”就可以了。

//抽象产品角色
public interface Car{
public void drive();
}
//具体产品角色
public class Benz implements Car{
public void drive() {
System.out.println("Driving Benz ");
}
}
public class Bmw implements Car{
public void drive() {
System.out.println("Driving Bmw ");
}
}
//工厂类角色
public class Driver{
//工厂方法.注意返回类型为抽象产品角色
public static Car driverCar(String s) {
//判断逻辑,返回具体的产品角色给Client
if(s.equalsIgnoreCase("Benz"))
return new Benz();
else if(s.equalsIgnoreCase("Bmw"))
return new Bmw();
}
}
//欢迎暴发户出场......
public class Magnate{
public static void main(String[] args){
//告诉司机我今天坐奔驰
Car car = Driver.driverCar("benz");
//下命令:开车
car.drive();
}
}


这便是简单工厂模式了。我们看一下使用简单工厂模式的好处

1)使用了简单工厂模式后,我们的程序不在“有病”,更加符合现实中的情况;

2)而且客户端免除了直接创建产品对象的责任,而仅仅负责“消费”产品(正如暴发户所为)。

简单工厂模式的缺点

对于工厂类角色(Creator)来说,每增加一辆车,都要在工厂类中增加相应的业务逻辑或者判断逻辑,这显然是违背开闭原则的。可想而知对于新产品的加入,工厂类是很被动的。

工厂方法模式

为了解决简单工厂模式的违背开闭原则的缺点,我们引入工厂方法模式:

工厂方法模式去掉了简单工厂模式中工厂方法的静态属性,使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。

你应该大致猜出了工厂方法模式的结构,来看下它的组成:

1) 抽象工厂角色(Creator): 这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java 中它由抽象类或者接口来实现。

2) 具体工厂角色(ConcreteCreator):它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。

3) 抽象产品角色(Product):它是具体产品继承的父类或者是实现的接口。在 java 中一般有抽象类或者接口来实现。

4) 具体产品角色(ConcreteProduct):具体工厂角色所创建的对象就是此角色的实例。在 java 中由具体的类来实现。

用类图来清晰的表示下的它们之间的关系:



工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说,这样便分担了对象承受的压力;而且这样使得结构变得灵活起来——当有新的产品(即暴发户的汽车)产生时,只要按照抽象产品角色、抽象工厂角色提供的合同来生成,那么就可以被客户使用,而不必去修改任何已有的代码。

//抽象产品角色
public interface Car {
public void drive();
}

//具体产品角色
public class Benz implements Car
{
public void drive() {
System.out.println("Driving Benz!");
}
}

//具体产品角色
public class Audi implements Car
{
public void drive() {
System.out.println("Driving Audi!");
}

}

//抽象工厂角色
public interface Driver {
public Car driveCar();
}

//具体工厂角色
public class BenzDriver implements Driver {
@Override
public Car driveCar() {
return new Benz();
}
}

//具体工厂角色
public class AudiDriver implements Driver {
@Override
public Car driveCar() {
return new Audi();
}
}

//客户使用
public  class Magnate
{
public static void main (String [] args)
{
Driver driver = new BenzDriver();
Car car = driver.driveCar();
car.drive();
}

}


可以看出工厂方法的加入,使得对象的数量成倍增加。当产品种类非常多时,会出现大量的与之对应的工厂对象,这不是我们所希望的。因为如果不能避免这种情况,可以使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类。

下面情况可以考虑使用工厂方法模式:

(1)当客户程序不需要知道要使用对象的创建过程。

(2)客户程序使用的对象存在变动的可能, 者根本就不知道使用 哪一个具体的对象。

简单工厂模式与简单工厂方法模式真正的避免了代码的改动了?没有。在简单工厂模式中,新产品的加入要修改工厂角色中的判断语句;而在工厂方法模式中,要么将判断逻辑留在抽象工厂角色中,要么在客户程序中将具体 工厂写死(就象上面的例子一样)。而且产品对象创建条件的改变必然会引起 工厂角色的修改。这种情况在java中利用反射机制与配置文件的巧妙结合突破了限制。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: