想想我们之前的简单工厂模式,是这样的:
结构图:
工厂类:
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 原型模式
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------