设计模式 创建模式之工厂家族

学习设计模式是程序员到设计人员的必经之路，灵活运用设计模式可以使我们的工作事半功倍，甚至一劳永逸。
今天学习了设计模式里面的工厂家族：简单工厂模式，工厂方法模式和抽象工厂模式。
参考资料：Java design.pdf 是一本老书了，作者：阎宏
这三个模式刚好是这本书最先介绍的三种模式，经过阅读，我觉得有必要把我的想法写出来。
这里的客户端调用是模拟可变的，就是说如果我们从实例化一个类改成实例化另一个类（即生产一种产品改成生产另一种产品），我们的代码的修改量是作为评价框架优劣的主要因素（追求灵活性，可扩展性）。
简单工厂
用一个工厂来统一生成一类商品的实例，当系统修改时，不需要修改具体的实现类，只需要更新工厂类。（不会贴图，类图就先不贴了，下同）
需求：我们需要两个产品，产品间的选择是不定的。
产品A

package com.aine.patter.product.simple;

public class ProductA{

	public void doSome() {
		System.out.println("I'm A, I can do A.");
	}

}

产品B

package com.aine.patter.product.simple;

public class ProductB{

	public void doSome() {
		System.out.println("I'm B, I can do B.");
	}

}

Client调用

public static void main(String [] args){
		System.out.println("I'm Simple Client begin.");
		
		//version 1 _S
		ProductA proA = new ProductA();
		proA.doSome();
		
		ProductB proB = new ProductB();
		proB.doSome();
		//version 1 _E
		
		System.out.println("I'm Simple Client end.");
	}

最后运行的结果是：

I'm Simple Client begin.
I'm A, I can do A.
I'm B, I can do B.
I'm Simple Client end.

这样应该是最基本的写法，也是最初级程序员的写法，我们来看看这样写的弊端：
1 客户端程序直接了解了产品类A,B，如果需要增加产品，客户端就必须重新认识，并且修改（将前两行mark掉，打开后面的代码）。
2 不满足依赖倒转原则。
运用简单工厂方法改造
抽象出产品接口

package com.aine.patter.product.simple;

public interface IProduct {
	public void doSome();
}

让所有产品实现接口：

package com.aine.patter.product.simple;

public class ProductA implements IProduct{

	@Override
	public void doSome() {
		System.out.println("I'm A, I can do A.");
	}

}

package com.aine.patter.product.simple;

public class ProductB implements IProduct{

	@Override
	public void doSome() {
		System.out.println("I'm B, I can do B.");
	}

}

新建工厂类，来分发请求：

package com.aine.patter.factory;

import com.aine.patter.product.simple.IProduct;
import com.aine.patter.product.simple.ProductA;
import com.aine.patter.product.simple.ProductB;

public class SimpleFactory {
	public static IProduct createProduct(String name) throws Exception{
		if("A".equalsIgnoreCase(name)){
			return new ProductA();
		}else if ("B".equalsIgnoreCase(name)){
			return new ProductB();
		}else{
			throw new Exception("No such product.");
		}
	}
}

客户端修改成：

package com.aine.patter.client;

import com.aine.patter.factory.SimpleFactory;
import com.aine.patter.product.simple.IProduct;

public class SimpleClinet {
	public static void main(String [] args){
		System.out.println("I'm Simple Client begin.");
		
		//version 1 _S
//		ProductA proA = new ProductA();
//		proA.doSome();
//		
//		ProductB proB = new ProductB();
//		proB.doSome();
		//version 1 _E
		
		//version 2 _S
		try {
			IProduct product = SimpleFactory.createProduct("A");
			product.doSome();
		} catch (Exception e) {
			e.printStackTrace();
		}
		//version 2 _E
		
		System.out.println("I'm Simple Client end.");
	}
}

执行的结果是：

I'm Simple Client begin.
I'm A, I can do A.
I'm Simple Client end.

分析：
优点：如此一来，将产品类的逻辑从客户端剥离到factory中了，如果以后需要实例化B而不是A的话，只需要在客户端选B 类型的product就可以了，这样大大减少了修改量。客户端使用了里氏代换原则，整个结构也满足了依赖倒转原则。
缺点：
1 如果要增加新的product，还是需要修改factory类里面的if判断，这样还是不符合开闭原则。
2 factory类需要学习所有的实现子类，职责太集中，如果factory出问题了，整个系统都出问题了。
3 factory中使用的是静态方法，无法通过继承等方式重构扩展。

演变
网上有帖子使用反射的原理来拓展factory，我觉得是简单工厂的演变，而不是工厂方法。

package com.aine.patter.factory;

import com.aine.patter.product.simple.IProduct;

public class SimpleFactory {
	public static IProduct createProduct() throws Exception {
		String className = "ProductA";// get from parameter
		String classPath = "com.aine.patter.product.simple." + className;
		IProduct product;
		try {
			product = (IProduct) Class.forName(classPath).newInstance();
		} catch (Exception e) {
			e.printStackTrace();
			product = null;
		}
		return product;
	}
}

这样是大大的灵活了工厂的实例化方法，并且解耦了工厂类和产品类，但是这个还是属于简单工厂模式。
工厂方法
针对简单工厂的遗留的缺点，我们使用工厂方法来解决。
缺点：
1 如果要增加新的product，还是需要修改factory类，这样还是不符合开闭原则。
2 factory类需要学习所有的实现子类，职责太集中，如果factory出问题了，整个系统都出问题了。
3 factory中使用的是静态方法，无法通过继承等方式重构扩展。
方案：
工厂的职责是什么？答曰：生产产品。那么我们能否将简单工厂中的if判断抽离，将所有的工厂抽象出来呢？答案是肯定的。
所以第一步，抽象一个工厂接口

package com.aine.patter.factory.method;

import com.aine.patter.product.simple.IProduct;

public interface IFactory {
	public IProduct createProduct();
}

然后新建每个商品的工厂类

package com.aine.patter.factory.method;

import com.aine.patter.product.simple.IProduct;
import com.aine.patter.product.simple.ProductA;

public class FactoryA implements IFactory{

	@Override
	public IProduct createProduct() {
		return new ProductA();
	}

}

package com.aine.patter.factory.method;

import com.aine.patter.product.simple.IProduct;
import com.aine.patter.product.simple.ProductB;

public class FactoryB implements IFactory{

	@Override
	public IProduct createProduct() {
		return new ProductB();
	}

}

客户端调用：

package com.aine.patter.client;

import com.aine.patter.factory.method.FactoryA;
import com.aine.patter.factory.method.IFactory;
import com.aine.patter.product.simple.IProduct;

public class MethodClient {
	public static void main(String [] args){
		System.out.println("I'm Method Client begin.");
		try {
			IFactory factory = new FactoryA();
			IProduct product = factory.createProduct();
			product.doSome();
		} catch (Exception e) {
			e.printStackTrace();
		}
		System.out.println("I'm Method Client end.");
	}
}

执行结果：

I'm Method Client begin.
I'm A, I can do A.
I'm Method Client end.

分析：
1 如果要建造ProductB只需要在客户端将工厂改成new FactoryB();
如果要新建ProductC需要增加工厂FactoryC，并在工厂中生产ProductC，客户端调用C工厂。
如此一来就满足了开闭原则。
2 简单工厂中的factory类 被分解成多个子类，实例化的工作被延迟到子类，分担了责任。
3 整个框架是面向接口编程的，符合了依赖倒转原则，是系统灵活多变，易于扩展。
Java中的应用
说几个我们熟悉的例子
1 EJB

package com.aine.patter.client;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class TestEJB {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		try {
			Context ctx = new InitialContext();
			EJBHome home = (EJBHome)ctx.lookup("EJBName");
			EJB ejb = home.create("aine");
			ejb.doSome();
		} catch (NamingException e) {
			e.printStackTrace();
		}
	}

}

2 JMS，Spring等等，代码就不贴了，大家应该都很熟悉这样的用法。
缺点：
如此完美的工厂方法还是有缺点的，那就是如果产品等级结构复杂了，工厂方法就无能为力了。
说的有点抽象，比方说我的例子里面的Product都是可以抽象出IProduct接口的，如果生产中需要构造不同的抽象接口的产品怎么办？举个不太准确的例子，我们之前的工厂是生产电脑的，很显然电脑是一个抽象的产品，因为根据不同厂家的实现不同，就实例化成不同的电脑了，比如联想电脑，华硕电脑，以及惠普电脑。如果单纯这样的区分我们使用工厂方法就可以handle了，因为这都是属于同一个产品等级结构的，换言之，都是统一的划分的。但是如果现在按照电脑卖给不同的人来划分不同的功能，卖给个人的电脑是PC，卖给公司是服务器，卖给商务人员是笔记本等等，这样的划分跟厂家实现的划分是不同的等级结构的，这样就变成了一个二维的分类组合：

	联想	华硕	惠普
PC	联想PC	华硕PC	惠普PC
服务器	联想服务器	华硕服务器	惠普服务器
终端	联想终端	华硕终端	惠普终端

这样的复杂的结构使用工厂方式就已经不能满足了，下面我们使用抽象工厂模式来解决这样的问题。
抽象工厂
讲抽象工厂之前必须要明确一个概念：产品族
产品族就是位于不同产品等级结构中，功能项关联的产品组成的家族。
比如上面的table，横向的是产品等级结构，通过不同厂商实现分厂了各个厂商的品牌等级，纵向就是产品族了，PC是一个产品族类型，因为它是将一类产品按照功能组合在一起的，同样服务器也是一个产品族类型。
抽象工厂就是用来生产这样复杂结构的产品的，具体的描述我就不写了，大家都能看到，我们来看实现：
1 根据产品族抽象产品类型（就以之前电脑的例子来说）。根据产品功能，我们抽象出2个产品族（当然可以更多）：PC机，服务器

package com.aine.patter.product.abst;

public interface IPCComputer {
	public void doPC();
}

package com.aine.patter.product.abst;

public interface IServiceComputer {
	public void doService();
}

2 根据产品族，定义工厂方法：这就好像知道了产品的种类，我们必须有对应的生产方法，这个方法是抽象方法

package com.aine.patter.factory.abst;

import com.aine.patter.product.abst.IPCComputer;
import com.aine.patter.product.abst.IServiceComputer;

public interface ICreateProduct {
	public IPCComputer createPC();
	
	public IServiceComputer createService();
}

这里一个产品族对应一个生产方法，可以理解吧？
3 将产品的子类补齐，因为是组合关系，我们就以联想和惠普为例：

package com.aine.patter.product.abst;

public class LenovoPC implements IPCComputer{

	@Override
	public void doPC() {
		System.out.println("I'm Lenovo PC, I can do PC.");
	}
	
}

package com.aine.patter.product.abst;

public class LenovoService implements IServiceComputer{

	@Override
	public void doService() {
		System.out.println("I'm Lenovo Service, I can do Service.");
	}
	
}

package com.aine.patter.product.abst;

public class HuipuPC implements IPCComputer{

	@Override
	public void doPC() {
		System.out.println("I'm Huipu PC, I can do PC.");
	}
	
}

package com.aine.patter.product.abst;

public class HuipuService implements IServiceComputer{

	@Override
	public void doService() {
		System.out.println("I'm Huipu Service, I can do Service.");
	}
	
}

3 和工厂方法一样，我们新建每个产品等级的工厂类

package com.aine.patter.factory.abst;

import com.aine.patter.product.abst.IPCComputer;
import com.aine.patter.product.abst.IServiceComputer;
import com.aine.patter.product.abst.LenovoPC;
import com.aine.patter.product.abst.LenovoService;

public class LenovoFactory implements ICreateProduct{

	@Override
	public IPCComputer createPC() {
		return new LenovoPC();
	}

	@Override
	public IServiceComputer createService() {
		return new LenovoService();
	}

}

package com.aine.patter.factory.abst;

import com.aine.patter.product.abst.HuipuPC;
import com.aine.patter.product.abst.HuipuService;
import com.aine.patter.product.abst.IPCComputer;
import com.aine.patter.product.abst.IServiceComputer;

public class HuipuFactory implements ICreateProduct{

	@Override
	public IPCComputer createPC() {
		return new HuipuPC();
	}

	@Override
	public IServiceComputer createService() {
		return new HuipuService();
	}

}

4 客户端代码就和工厂方法一样了：

package com.aine.patter.client;

import com.aine.patter.factory.abst.ICreateProduct;
import com.aine.patter.factory.abst.LenovoFactory;
import com.aine.patter.product.abst.IPCComputer;
import com.aine.patter.product.abst.IServiceComputer;

public class AbstractClient {
	public static void main(String [] args){
		System.out.println("I'm Abstract Client begin.");
		try {
			ICreateProduct factory = new LenovoFactory();
			IPCComputer pc = factory.createPC();
			pc.doPC();
			
			IServiceComputer service = factory.createService();
			service.doService();
		} catch (Exception e) {
			e.printStackTrace();
		}
		System.out.println("I'm Abstract Client end.");
	}
}

5 执行结果：

I'm Abstract Client begin.
I'm Lenovo PC, I can do PC.
I'm Lenovo Service, I can do Service.
I'm Abstract Client end.

如果需要生产惠普的机器，我们只要将客户端改成 new HuipuFactory();其他的都不用改，是不是将修改限制在最少了？
6 分析：
关于开闭原则：
当我们尝试增加一个产品等级机构的时候，我们只需要增加工厂，然后增加产品等级的实现类，这样是符合开闭原则的（同工厂方法）。
如果我们尝试增加一个产品族，我们不仅需要增加产品的抽象类，还要修改抽象工厂的工厂方法，因为对于一种新功能的产品，我们要提供相应的生产方法，进而这样就导致每个厂商都要提供相应的实现方法了。这是不满足开闭原则的。
这里我的理解跟书上写的是反的，不知道是谁的对，个人理解，希望大家一起讨论下。

总结
至此，大家是不是跟我一样对工厂家族有了一个新的认识啊？现在再回过头来看自己写的代码，我发现有好多地方可以重构下。
那我就不浪费时间了，赶紧去改了。
记录以备查阅。