设计模式（六）工厂方法模式

想想我们之前的简单工厂模式，是这样的：

结构图：

工厂类：

class OperationFactory{
    public static Operation createOperate(string operate){
        Operation oper =null;
        switch(operate){
            case "+":
                oper=new OperationAdd();
                break;
            case "-":
                oper=new OperationSub();
                break;
            case "*":
                oper=new OperationMul();
                break;
            case "/":
                oper=new OperationDiv();
                break;
        }
        return oper;
    }
}

客户端：

Operation oper ;
oper=OperationFactory.createOperate("+");
oper.NumberA=1;
oper.NumberB=2;
double result =  oper.GetResult;

 

那么，换成工厂模式呢？

结构图：

先构建一个工厂接口：

interface IFactory{
    Operation CreateOperation();
}

然后加减乘除各建一个具体工厂去实现这个接口：

class AddFactory : IFactory{    // 加法类工厂
    public Operation CreateOperation(){
        return new OperationAdd();
    }
}

class SubFactory : IFactory{    // 减法类工厂
    public Operation CreateOperation(){
        return new OperationSub();
    }
}

class MulFactory : IFactory{    // 乘法类工厂
    public Operation CreateOperation(){
        return new OperationMul();
    }
}

class DivFactory : IFactory{    // 除法类工厂
    public Operation CreateOperation(){
        return new OperationDiv();
    }
}

客户端的实现是这样的：

IFactory operFactory = new addFactory();
Operation oper = operFactory.CreateOperation();
oper.NumberA=1;
oper.NumberB=1;
double result=oper.GetResult();

 

问题来了，以前我们说过，如果我现在需要增加其他运算，比如求M数的N次方，或者求M数的N次方根，这些功能的增加，在简单工厂里，是先去加“求M数的N次方”功能类，然后去更改工厂方法，当中加“Case”语句来做判断。现在用了工厂方法，加功能类没问题，再加相关的工厂类，这也没问题，但要我们再去更改客户端，这不等于不但没有减化难度，反而增加了很多类和方法，把复杂性增加了吗？

其实，这就是工厂方法模式和简单工厂的区别所在。简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。就像之前的计算器，让客户端不用管该用哪个类的实例，只需要把“+”给工厂，工厂自动就给出了相应的实例，客户端只要去做运算就可以了，不同的实例会实现不同的运算。但问题也就在这里，如果要加一个“求M数的N次方”的功能，我们是一定需要给运算工厂类的方法里加“Case”的分支条件的。——修改原有的类？这就违背了开放－封闭原则。

于是，工厂方法就来了——

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

结构图：

我们讲过，既然简单工厂模式中工厂类与分支耦合，那么我们就对它下手，根据依赖倒转原则，我们把工厂类抽象出一个接口，这个接口只有一个方法，就是创建抽象产品的工厂方法。然后，所有的要生产具体类的工厂，就去实现这个接口。这样，一个简单工厂模式的工厂类，变成了一个工厂抽象接口和多个具体生成对象的工厂。于是我们要增加“求M数的N次方”的功能时，就不需要更改原有的工厂了，只需要增加此功能的运算类和相应的工厂类就可以了。

工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。你想要加功能，本来是改工厂类的，而现在是修改客户端。

 

考虑一个需求：薛磊风是一个大学生，以学雷锋做好事的名义去帮助老人做事，现在们需要代替他去做好事，如何设计？

雷锋类：

// 雷锋
class LeiFeng{
    public void Sweep(){
        Console.WriteLine("扫地");
    }
    public void Wash(){
        Console.WriteLine("洗衣");
    }
    public void BuyRice(){
        Console.WriteLine("买米");
    }
        
}

学雷锋的大学生类，继承雷锋：

// 学雷锋的大学生
class Undergraduate:LeiFeng{}

客户端：

LeiFeng xueleifeng =new =Undergraduate();

xueleifeng.BuyRice();
xueleifeng.Sweep();
xueleifeng.Wash();

现在假设你们有三个人要去代替他做这些事，该怎么写？

似乎应该实例化三个“学雷锋的大学生”对象？

LeiFeng student1 = new Undergraduate();
student1.Buyrice();

LeiFeng student2 = new Undergraduate();
student2.Sweep();

LeiFeng student3 = new Undergraduate();
student3.Wash();

大学生都是要毕业的，而帮助老人却是长期工作，所以“社区志愿者”更合适。此时这样的写法就非常不合适了，因为我们需要更改多个实例化的地方。 

增加一个继承“雷锋”类的“社区志愿者”类： 

// 社区志愿者
class Volunteer : LeiFeng{}

再写简单工厂类：

// 简单雷锋工厂
class SimpleFactory{
    public static LeiFeng CreateLeiFeng(string type){
        LeiFeng result = null;
        switch(type){
            case "学雷锋的大学生":
                result = new Undergraduate();
                break;
            case "社区志愿者":
                result = new Volunteer();
                break;
        }
        return result;
    }
}

客户端的代码，如果要换，就只需换“学雷锋的大学生”为“社区志愿者”

// 简单工厂模式
LeiFeng studentA = SimpleFactory.CreatedLeiFeng("学雷锋的大学生");
studentA.BuyRice();
LeiFeng studentB = SimpleFactory.CreatedLeiFeng("学雷锋的大学生");
studentB.Sweep();
LeiFeng studentC = SimpleFactory.CreatedLeiFeng("学雷锋的大学生");
studentC.Wash();

// 三句重复的代码

然后你会发现，你需要在任何实例化的时候写出这个工厂的代码。这里有重复，也就有了坏味道。

再用工厂方法模式写一遍？

// 雷锋工厂
interface IFactory{
    LeiFeng CreateLeiFactory();
}

// 学雷锋的大学生工厂
class UndergraduateFactorry : IFactory{
    public LeiFeng CreateLeiFeng(){
        return new Undergraduate();
    }
}

// 社区志愿者工厂
class VolunteerFactory:Ifactory{
    public LeiFeng CreateLeiFeng(){
        return new Volunteer();
    }
}

客户端调用：

// 工厂方法模式
IFactory factory = new UndergraduateFactory();
LeiFeng student =factory.CreateLeiFeng();    // 要换成"社区志愿者"，修改这里就可以
    
student.BuyRice();
student.Sweep();
student.Wash();

 

总结一下——

工厂方法克服了简单工厂违背开放－封闭原则的缺点，又保持了封装对象创建过程的优点。工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。但缺点是由于每加一个产品，就需要加一个产品工厂的类，增加了额外的开发量。

那么，有没有最佳做法呢？

哈，其实，利用“反射”可以解决避免分支判断的问题！反射是什么？别急，接下来，我们会慢慢讲到......

 

 

本章完。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 本文是连载文章，此为第六章，学习遵循对简单工厂模式进行改进的工厂方法模式。

上一章：https://blog.csdn.net/qq_36770641/article/details/82765745  代理模式

下一章：https://blog.csdn.net/qq_36770641/article/details/82804903  原型模式

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------