工厂制造细节无需知--工厂方法模式

1.1 需要了解工厂制造细节吗？

"简单工厂只是最基本的创建实例相关的设计模式。但真实情况中，有更多复杂的情况需要处理。简单工厂生成实例的类，知道了太多的细节，这就导致这个类很容易出现难维护、灵活性差问题，让人感觉到了不好的味道。"
"知道很多细节不太好吗？"
"现实中，我们要想过好生活，是不太需要也不太可能知道所有细节的。比如说，我们知道猪长什么样子，也知道红烧肉很好吃，但一头猪是通过怎么样的过程变成红烧肉的呢？养殖、运输、屠宰、销售过程的批发、零售，还有饭店或家里的烹饪过程，对我们来说，都是不需要去了解的。我们去饭店吃饭，只要点了红烧肉，过一会儿它就被送出来了，好吃就行了，你说对不对？"

"将来如果能生产出这样一台机器，送进去是猪，出来就是红烧肉，那就好了。"
"嘿嘿！这样的机器我不知道是否生产得出来。不过，整个过程也算是一种封装吧。在我们的程序中，确实存在封装实例创建过程的模式——工厂方法模式，这个模式可以让创建实例的过程封装到工厂类中，避免耦合。它与简单工厂模式是一个体系的，你可以去研究一下。"

1.2 简单工厂模式实现

工厂类是这样写的

package code.chapter1.calculator4;

public class OperationFactory {

    public static Operation createOperate(String operate){
        Operation oper = null;
        switch (operate) {
            case "+":
                oper = new Add();
                break;
            case "-":
                oper = new Sub();
                break;
            case "*":
                oper = new Mul();
                break;
            case "/":
                oper = new Div();
                break;
        }
        return oper;
    }
    
}

客户端是这样的

package code.chapter8.calculator1;

import java.util.Scanner;

public class Test {

	public static void main(String[] args){

		System.out.println("**********************************************");		
		System.out.println("《大话设计模式》代码样例");
		System.out.println();		

		try {
			Scanner sc = new Scanner(System.in);

			System.out.println("请输入数字A：");	
			double numberA = Double.parseDouble(sc.nextLine());
			System.out.println("请选择运算符号(+、-、*、/)：");	
			String strOperate = sc.nextLine();
			System.out.println("请输入数字B：");	
			double numberB = Double.parseDouble(sc.nextLine());
			
			Operation oper = OperationFactory.createOperate(strOperate);
			
			double result = oper.getResult(numberA,numberB);

			System.out.println("结果是："+result);	
		}
		catch(Exception e){
			System.out.println("您的输入有错："+e.toString());	
		}

		System.out.println();
		System.out.println("**********************************************");

	}
}

1.3 工厂方法模式实现

先建一个工厂接口：

package code.chapter8.calculator1;

public interface IFactory {

    public Operation createOperation();
    
}

package code.chapter8.calculator1;

//加法工厂
public class AddFactory implements IFactory {

    public Operation createOperation(){
        return new Add();
    }
    
}

package code.chapter8.calculator1;

//乘法工厂
public class MulFactory implements IFactory {

    public Operation createOperation(){
        return new Mul();
    }
    
}

package code.chapter8.calculator1;

//减法工厂
public class SubFactory implements IFactory {

    public Operation createOperation(){
        return new Sub();
    }
    
}

package code.chapter8.calculator1;

//除法工厂
public class DivFactory implements IFactory {

    public Operation createOperation(){
        return new Div();
    }
    
}

package code.chapter8.calculator1;

public class OperationFactory {

    public static Operation createOperate(String operate){
        Operation oper = null;
        IFactory factory = null;
        switch (operate) {
            case "+":
                factory = new AddFactory();
                break;
            case "-":
                factory = new SubFactory();
                break;
            case "*":
                factory = new MulFactory();
                break;
            case "/":
                factory = new DivFactory();
                break;
        }
        oper = factory.createOperation();
                
        return oper;
    }
    
}

1.4 简单工厂vs.工厂方法

"怪就怪在这里呀，以前我们不是说过，如果我现在需要增加其他运算，比如求x的n次方（xn），或者求a为底数b的对数（logab），这些功能的增加，在简单工厂里，我是先去加求x的n次方的指数运算类，然后去更改OperationFactory类，当中加'Case'语句来做判断。现在用了工厂方法，加指数运算类没问题，去改OperationFactory类的分支也没问题，但又增加了一个指数工厂类，这不等于不但没有降低难度，反而增加类，把复杂性增加了吗？为什么要这样？"
"问得好。简单工厂模式的最大优点在于工厂类中包含必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。就像你的计算器，让客户端不用管该用哪个类的实例，只需要把'+'给工厂，工厂自动就给出了相应的实例，客户端只要去做运算就可以了，不同的实例会实现不同的运算。但问题也就在这里，如你所说，如果要加一个'求x的n次方（xn）'的功能，我们需要给OperationFactory类的方法里加'Case'的分支条件。目前来看，这个OperationFactory类，承载了太多功能，这可不是好办法。这就等于说，我们不但对扩展开放了，对修改也开放了，这样就违背了什么原则？"
"哦，是的，违背的是开放-封闭原则。"
"对，也就是说，我们加减乘除运算的部分已经相当成熟了，但是因为增加新的功能，就要去改已经很成熟的类代码，这就好比很多鸡蛋放在了一个篮子里，这是很危险的。"
"那么工厂方法模式，就可以解决这个问题吗？我感觉我本来是4个运算类，1个工厂类，共5个类，现在多出了4个运算工厂类和1个工厂接口，问题依然没有解决。"
"哈哈，那是因为你没有真的理解工厂方法。举一个例子，我们公司本来只有一家工厂，生产四种不同的产品。后来发展得特别好，需要增加新的两种产品放在另一个地方开设新的工厂。新的工厂不应该影响原有工厂的正常工作，你说怎么办？"
"新工厂建在别的地方，应该不影响原有的工厂运作，最多就是建好后，总公司那里再增加一些协调管理部门就好了。"
"说得非常好。就编程来说，我们应该尽量将长的代码分派切割成小段，再将每一小段'封装'起来，减少每段代码之间的耦合，这样风险就分散了，需要修改或扩展的难度就降低了。加减乘除四个类算是一个工厂的产品，不妨叫它们（基础运算工厂）类，现在增加指数、对数运算类，如果算是另一种工厂的两种产品，不妨称它为'高级运算工厂'类，你觉得有必要去影响原有的基础运算工厂运作吗？"
"哦！我明白你的意思了。并不是要去创建加法工厂、减法工厂这样的类，而是将加减乘除用一个基础工厂来创建，现在增加了新的产品，又不想影响原有的工厂代码，于是就扩展一个新的工厂来处理。我马上改。"
"下面是原有的工厂结构，加减乘除运算已经非常稳定，尽量不要去改变它们。"

"增加了一种新的工厂和两种新的运算类（以后可以扩展更多的高级运算，比如正余弦、正余切等），不要影响原有的代码和运作。"

"增加两个运算类。"

package code.chapter8.calculator2;

//指数运算类，求numberA的numberB次方
public class Pow extends Operation {

    public double getResult(double numberA, double numberB){
        //此处缺两参数的有效性检测
        return Math.pow(numberA,numberB);
    }
    
}

package code.chapter8.calculator2;

//对数运算类，求以numberA为底的numberB的对数
public class Log extends Operation {

    public double getResult(double numberA, double numberB){
        //此处缺两参数的有效性检测
        return Math.log(numberB)/Math.log(numberA);
    }
    
}

工厂接口不变：

package code.chapter8.calculator2;

public interface IFactory {

    public Operation createOperation(String operType);
    
}

"基础运算工厂类，此类已经比较成熟稳定，实现后应该封装到位，不建议轻易修改。"

package code.chapter8.calculator2;

//基础运算工厂
public class FactoryBasic implements IFactory {

    public Operation createOperation(String operType){
        Operation oper = null;
        switch (operType) {
            case "+":
                oper = new Add();
                break;
            case "-":
                oper = new Sub();
                break;
            case "*":
                oper = new Mul();
                break;
            case "/":
                oper = new Div();
                break;
        }
                
        return oper;
    }
    
}

"高级运算工厂类，也许还有扩展产品的可能。"

package code.chapter8.calculator2;

//高级运算工厂
public class FactoryAdvanced implements IFactory {

    public Operation createOperation(String operType){
        Operation oper = null;
        switch (operType) {
            case "pow":
                oper = new Pow();//指数运算类实例
                break;
            case "log":
                oper = new Log();//对数运算类实例
                break;

            //此处可扩展其他高级运算类的实例化，但修改
            //当前工厂类不会影响到基础运算工厂类

        }
                
        return oper;
    }    
}

"左侧新的OperationFactory类与右侧原来的OperationFactory类对比。"

package code.chapter8.calculator2;

public class OperationFactory {

    public static Operation createOperate(String operate){
        Operation oper = null;
        IFactory factory = null;
        switch (operate) {
            case "+":
            case "-":
            case "*":
            case "/":
                //基础运算工厂实例
                factory=new FactoryBasic();
                break;
            case "pow":
            case "log":
                //高级运算工厂实例
                factory=new FactoryAdvanced();
                break;
        }  
        //利用多态返回实际的运算类实例
        oper = factory.createOperation(operate);
        return oper;
    }
}

"你或许会发现，新的Opera口与具体工厂类，并不存在具体的实现，与原来的OperationFactory类对比，实例化的过程延迟到了工厂子类中。"不过新的OperationFactory类依然存在'坏味道'，当增加新的运算子类时，它本身也是需要更改的，这个先放在一边，以后可以解决。"
"Perfect！我明白了。这就是前面提到的针对接口编程，不要对实现编程吧？"
"是的。我们来看工厂方法的定义。注意关键词——延迟到子类。"

工厂方法模式（Factory Method），定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。［DP］

工厂方法模式（Factory Method）结构图

package code.chapter8.factorymethod;

public class Test {

	public static void main(String[] args){

		System.out.println("**********************************************");		
		System.out.println("《大话设计模式》代码样例");
		System.out.println();		

		Creator[] creators = new Creator[2];
		creators[0] = new ConcreteCreatorA();
		creators[1] = new ConcreteCreatorB();

		for(Creator item : creators){
			Product product = item.factoryMethod();
			product.make();
		}

		System.out.println();
		System.out.println("**********************************************");

	}
}

//Product类
abstract class Product {
	public abstract void make();
}

//ConcreteProductA类
class ConcreteProductA extends Product {
	public void make(){
		System.out.println("产品A制造");
	}
}

//ConcreteProductB类
class ConcreteProductB extends Product {
	public void make(){
		System.out.println("产品B制造");
	}
}

//Creator类
abstract class Creator {
	public abstract Product factoryMethod();
}

class ConcreteCreatorA extends Creator{
	public Product factoryMethod(){
		return new ConcreteProductA();
	}
}

class ConcreteCreatorB extends Creator{
	public Product factoryMethod(){
		return new ConcreteProductB();
	}
}

"我们讲过，既然这个工厂类与分支耦合，那么我就对它下手，根据依赖倒转原则，我们把工厂类抽象出一个接口，这个接口只有一个方法，就是创建抽象产品的工厂方法。然后，所有的要生产具体类的工厂，就去实现这个接口，这样，一个简单工厂模式的工厂类，变成了一个工厂抽象接口具体生成对象的工厂。每个工厂可以有多个不同产品，而工厂之间，又是相对隔离封装状态。这样过去已经比较完善的工厂和产品体系，就不需要再去改动它们，而另外需要变更的代码，完全可以通过扩展来变化，这就完全符合了开放-封闭原则的精神。"
"哦，工厂方法从这个角度讲，的确要比简单工厂模式来得强。"
"严格来说，是一种升级。当只有一个工厂时，就是简单工作模式，当有多个工厂时，就是工厂方法模式。类似由一维进化成了二维，更强大了。"

1.5 商场收银程序再再升级

package code.chapter6.decorator5;

public class CashContext {

    private ISale cs;   //声明一个ISale接口对象

    //通过构造方法，传入具体的收费策略
    public CashContext(int cashType){
        switch(cashType){
            case 1:
                this.cs = new CashNormal();
                break;
            case 2:
                this.cs = new CashRebate(0.8d);
                break;
            case 3:
                this.cs = new CashRebate(0.7d);
                break;
            case 4:
                this.cs = new CashReturn(300d,100d);
                break;
            case 5:
                //先打8折,再满300返100
                CashNormal cn = new CashNormal();
                CashReturn cr1 = new CashReturn(300d,100d); 
                CashRebate cr2 = new CashRebate(0.8d);
                cr1.decorate(cn);   //用满300返100算法包装基本的原价算法
                cr2.decorate(cr1);  //打8折算法装饰满300返100算法
                this.cs = cr2;      //将包装好的算法组合引用传递给cs对象
                break;
            case 6:
                //先满200返50，再打7折
                CashNormal cn2 = new CashNormal();
                CashRebate cr3 = new CashRebate(0.7d);
                CashReturn cr4 = new CashReturn(200d,50d); 
                cr3.decorate(cn2);  //用打7折算法包装基本的原价算法
                cr4.decorate(cr3);  //满200返50算法装饰打7折算法
                this.cs = cr4;      //将包装好的算法组合引用传递给cs对象
                break;
        }
    }

    public double getResult(double price,int num){
        //根据收费策略的不同，获得计算结果
        return this.cs.acceptCash(price,num);
    }    
}

"以前不觉得，现在发现确实是太多的new实例了，尤其是5和6，装饰模式的使用，在这个CashContext类中，显得特别的复杂。"

创建几个工厂类来处理这些new?

"从上面的代码来看，我感觉至少应该有原价销售类、打折类、满减返利类、先打折再满减类和先满减再打折类，一共五个工厂类。"

"尝试抽象一下，能不能合并一部分呢？"

"我想想。好像原价类，可以想象成打折的参数为1的打折类。但打折与满减返利好像合并不了。"

"它俩是合并不了，但先打折后满减类能不能涵盖它们俩？"

"我懂了。如果有'先打折后满减类'存在，那它应该有三个初始化参数：折扣值、满减条件、满减返利值，那么打折类，其实就是满减返利值条件为0的情况，另外满减类，就相当于折扣参数为1的情况。"那就只需要'先打折再满减'和'先满减再打折'两个工厂类了。"

1.6 简单工厂+策略+装饰+工厂方法

"我的实现方法，首先原有的ISale、CashSuper、CashNormal、CashReturn、CashRebate等类都不变。"

"增加IFactory接口。"

package code.chapter8.factorymethod1;

public interface IFactory {

   public ISale createSalesModel(); //创建销售模式

}

"增加实现IFactory接口的两个类，'先打折再满减'类和'先满减再打折'类，其中红框部分代码为装饰模式的实现。"

package code.chapter8.factorymethod1;

//先打折再满减类
public class CashRebateReturnFactory implements IFactory {
    
    private double moneyRebate = 1d;
    private double moneyCondition = 0d;
    private double moneyReturn = 0d;

    public CashRebateReturnFactory(double moneyRebate,double moneyCondition,double moneyReturn){
      this.moneyRebate=moneyRebate;
      this.moneyCondition=moneyCondition;
      this.moneyReturn=moneyReturn;
    }

    //先打x折,再满m返n
    public ISale createSalesModel(){
        
        CashNormal cn = new CashNormal();
        CashReturn cr1 = new CashReturn(this.moneyCondition,this.moneyReturn); 
        CashRebate cr2 = new CashRebate(this.moneyRebate);
        
        cr1.decorate(cn);   //用满m返n算法包装基本的原价算法
        cr2.decorate(cr1);  //打x折算法装饰满m返n算法
        return cr2;         //将包装好的算法组合返回
    }    
}

package code.chapter8.factorymethod1;

//先满减再打折类
public class CashReturnRebateFactory implements IFactory {
    
    private double moneyRebate = 1d;
    private double moneyCondition = 0d;
    private double moneyReturn = 0d;

    public CashReturnRebateFactory(double moneyRebate,double moneyCondition,double moneyReturn){
      this.moneyRebate=moneyRebate;
      this.moneyCondition=moneyCondition;
      this.moneyReturn=moneyReturn;
    }

    //先满m返n,再打x折
    public ISale createSalesModel(){
        
        CashNormal cn2 = new CashNormal();
        CashRebate cr3 = new CashRebate(this.moneyRebate);
        CashReturn cr4 = new CashReturn(this.moneyCondition,this.moneyReturn); 

        cr3.decorate(cn2);  //用打x折算法包装基本的原价算法
        cr4.decorate(cr3);  //满m返n算法装饰打x折算法
        return cr4;         //将包装好的算法组合返回
    }    
}

"有了上面的这些准备后，CashContext类就简单多了，它针对的是ISale接口、IFactory接口编程，然后两个工厂类，对于各个打折满减算法CashSuper、CashNormal、CashReturn、CashRebate等具体类一无所知。实现了松耦合的目的。"

package code.chapter8.factorymethod1;

public class CashContext {
    private ISale cs;   //声明一个ISale接口对象
    //通过构造方法，传入具体的收费策略
    public CashContext(int cashType){
        IFactory fs=null;
        switch(cashType) {
            case 1://原价
                fs = new CashRebateReturnFactory(1d,0d,0d);
                break;
            case 2://打8折
                fs = new CashRebateReturnFactory(0.8d,0d,0d);
                break;
            case 3://打7折
                fs = new CashRebateReturnFactory(0.7d,0d,0d);
                break;
            case 4://满300返100
                fs = new CashRebateReturnFactory(1,300d,100d);
                break;
            case 5://先打8折,再满300返100
                fs = new CashRebateReturnFactory(0.8d,300d,100d);
                break;
            case 6://先满200返50，再打7折
                fs = new CashReturnRebateFactory(0.7d,200d,50d);
                break;
        }
        this.cs = fs.createSalesModel();
    }

    public double getResult(double price,int num){
        //根据收费策略的不同，获得计算结果
        return this.cs.acceptCash(price,num);
    }    
}

"我感觉工厂方法克服了简单工厂违背开放-封闭原则的缺点，又保持了封装对象创建过程的优点。"
大鸟："说得好，它们都是集中封装了对象的创建，使得要更换对象时，不需要做大的改动就可实现，降低了客户程序与产品对象的耦合。工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。就像生活中，凡是在基层工作过的人都知道，具体事情做得越多，越容易犯错误。相反，如果做官做得高了，说出的话就会比较抽象、笼统，很多时候犯错误的可能性反而就越来越小了。"
"工厂方法模式是不是本质就是对获取对象过程的抽象？"
"说得非常对，就是这样。工厂方法的好处有这么几条：第一，对于复杂的参数的构造对象，可以很好地对外层屏蔽代码的复杂性，注意是指创建新实例的构造对象。比如说我们用了'先打折再满减'类工厂，其实就屏蔽了装饰模式的一部分代码，让CashContext不再需要了解装饰的过程。第二，很好的解耦能力。这点刚才你也说了，这就是针对接口在编程。当我们要修改具体实现层的代码时，上层代码完全不了解实现层的情况，因此并不会影响到上层代码的调用，这就达到了解耦的目的。"
"对了。你说这还不是最佳的做法？那应该如何做呢？还有就是这样还是没有避免修改客户端的代码呀？"
"哈，之前我就提到过，利用'反射'可以解决避免分支判断的问题。不过今天还是不急，等以后再谈。"
"好的好的。你饿了吗？我们要不去撸串吃点夜宵？"
"走！去吃封装羊肉去。"