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

在实际应用中,很可能产品是一个多层次的树状结构。

        由于简单工厂模式中只有一个工厂类来对应这些产品,所以这可能会把我们的上帝累坏了,也累坏了我们这些程序员,于是工厂方法模式作为救世主出现了。

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


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

  1. 抽象工厂角色: 这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java 中它由抽象类或者接口来实现。
  2. 具体工厂角色:它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
  3. 抽象产品角色:它是具体产品继承的父类或者是实现的接口。在 java 中一般有抽象类或者接口来实现。
  4. 具体产品角色:具体工厂角色所创建的对象就是此角色的实例。在 java 中由具体的类来实现。

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

        工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说,这样便分担了对象承受的压力;而且这样使得结构变得灵活起来。


        当有新的产品产生时,只要按照抽象产品角色、抽象工厂角色提供的合同来生成,那么就可以被客户使用,而不必去修改任何已有的代码。可以看出工厂角色的结构也是符合开闭原则的!


        我们还是老规矩,使用一个完整的例子来看看工厂模式各个角色之间是如何来协调的。话说惠普公司需要制造更多类型的打印机,普通打印机有好几个品种,高速打印机也有好几个品种,如果都放在一个工厂生产,会显得杂乱无章,这下惠普公司成了两个工厂部门,一个专门负责生产普通打印机,一个专门负责生产高速打印机。于是,工厂方法模式的管理出现了。


代码如下:

抽象产品角色(我们定义了一个打印机)

public abstract class Printer
{
	public abstract void out();
	
	public abstract void getData(String msg);
}


具体产品角色(我们定义两个产品,一个是普通打印机,一个是高速打印机)

/*
 * 高速打印机
 */
public class BetterPrinter extends Printer
{
	private  final int MAX_CACHE_LINE = 10;
	private String[] printData = new String[MAX_CACHE_LINE * 2];
	
	private int dataNum = 0;

	@Override
	public void getData(String msg)
	{
		if(dataNum >= MAX_CACHE_LINE * 2)
		{
			System.out.println("输出队列已满,添加失败");
		}
		else
		{
			printData[dataNum++] = msg;
		}
	}

	@Override
	public void out()
	{
		while(dataNum>0)
		{
			System.out.println("高速打印机打印: "+printData[0]);
			
			System.arraycopy(printData,1,printData,0,--dataNum);
		}
	}
}


/*
 * 普通打印机
 */
public class CommonPrinter extends Printer
{
	private  final int MAX_CACHE_LINE = 10;
	private String[] printData = new String[MAX_CACHE_LINE];
	
	private int dataNum = 0;

	@Override
	public void getData(String msg)
	{
		if(dataNum >= MAX_CACHE_LINE)
		{
			System.out.println("输出队列已满,添加失败");
		}
		else
		{
			printData[dataNum++] = msg;
		}
	}

	@Override
	public void out()
	{
		while(dataNum>0)
		{
			System.out.println("普通打印机打印: "+printData[0]);
			
			System.arraycopy(printData,1,printData,0,--dataNum);
		}
	}
}

抽象工厂角色

public interface PrinterFactory
{
	public Printer getPrinter();
}

具体工厂角色(我们定义两个工厂,一个是普通打印机工厂,一个是高速打印机工厂)

/*
 * 高速打印机工厂,只返回高速打印机产品
 */
public class BetterPrinterFactory implements PrinterFactory
{

	public Printer getPrinter()
	{
		return new BetterPrinter();
	}
}


/*
 * 普通打印机工厂,只返回普通打印机产品
 */
public class CommonPrinterFactory implements PrinterFactory
{

	public Printer getPrinter()
	{
		return new CommonPrinter();
	}
}



最后是测试了,我们定义一台计算机,由它调用工厂去生产我们需要的打印机,需要什么类型的打印机,就new出对应的工厂,由它来生产我们需要的打印机。

public class Computer
{
	private Printer out;

	public Computer(Printer out)
	{
		this.out = out;
	}
	public void keyIn(String msg)
	{
		out.getData(msg);
	}
	public void print()
	{
		out.out();
	}
	public static void main(String[] args)
	{
		PrinterFactory of = new CommonPrinterFactory();
		Computer c = new Computer(of.getPrinter());
		c.keyIn("hello");
		c.keyIn("world");
		c.print();
	}
}

打印结果:

普通打印机打印: hello
普通打印机打印: world

       可以看出工厂方法的加入,使得对象的数量成倍增长。当产品种类非常多时,会出现大量的与之对应的工厂对象,这不是我们所希望的。因为如果不能避免这种情况,可以考虑使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类:即对于产品树上类似的种类(一般是树的叶子中互为兄弟的)使用简单工厂模式来实现。

       工厂方法模式仿佛已经很完美的对对象的创建进行了包装,使得客户程序中仅仅处理抽象产品角色提供的接口。那我们是否一定要在代码中遍布工厂呢?大可不必。也许在下面情况下你可以考虑使用工厂方法模式:

  • 当客户程序不需要知道要使用对象的创建过程。
  • 客户程序使用的对象存在变动的可能,或者根本就不知道使用哪一个具体的对象。
       简单工厂模式与工厂方法模式真正的避免了代码的改动了?没有。在简单工厂模式中,新产品的加入要修改工厂角色中的判断语句;而在工厂方法模式中,要么将判断逻辑留在抽象工厂角色中,要么在客户程序中将具体工厂角色写死(就象上面的例子一样)。而且产品对象创建条件的改变必然会引起工厂角色的修改。

       面对这种情况,Java 的反射机制与配置文件的巧妙结合突破了限制——这在Spring 中完美的体现了出来。

java设计模式(2):工厂方法模式(Factory Method),古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。