在软件系统中,经常面临着创建对象的工作;由于需求的变化,需要创建的对象的具体类型经常变化。
如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合?
工厂模式主要是针对对象创建过程。来看这样一个代码
Product *product=new ProductA();
有啥问题?如果类中出现了类似代码,说明这个类对这个ProductA产生了依赖,不符合依赖倒置原则。出现的问题是:第一,因为new这个代码比较简单,如果是创建比较复杂的对象,且要多次创建,在每个创建的时候是不是都要写一遍?第二,如果这个代码在类中出现多次,你后边想换一个(业务场景变了),要用ProductB,是不是整个类中但凡出现的全都得改?
所以,抽象工厂解决了两个问题,一个是解耦,然后是减少代码量。
这么说可能不太清晰,还是举个例子。
我有一个主对话框MainForm,然后我要做文件分割FileSplitter。那么这个代码我可以这样写(伪代码)
class ISplitter{
public:
virtual void split()=0;
virtual ~ISplitter(){}
};
class BinarySplitter : public ISplitter{
};
class FileSplitter: public ISplitter{
};
class PictureSplitter: public ISplitter{
};
class VideoSplitter: public ISplitter{
};
class MainForm : public Form
{
public:
void Button1_Click(){
ISplitter * splitter=
new FileSplitter();//依赖具体类
splitter->split();
}
};
文件分割我们还是设计成有扩展功能,因为还涉及到什么视频分割、图片分割,都要支持。这个代码就很明显有个问题,因为文件分割在后续的业务需要扩展,你这个就完全依赖于FileSplitter依赖死了,耦合度很高啊。
那来看看怎么处理:
//抽象类
class ISplitter{
public:
virtual void split()=0;
virtual ~ISplitter(){}
};
//工厂基类
class SplitterFactory{
public:
virtual ISplitter* CreateSplitter()=0;
virtual ~SplitterFactory(){}
};
//具体类
class BinarySplitter : public ISplitter{
};
class TxtSplitter: public ISplitter{
};
class PictureSplitter: public ISplitter{
};
class VideoSplitter: public ISplitter{
};
//具体工厂
class BinarySplitterFactory: public SplitterFactory{
public:
virtual ISplitter* CreateSplitter(){
return new BinarySplitter();
}
};
class TxtSplitterFactory: public SplitterFactory{
public:
virtual ISplitter* CreateSplitter(){
return new TxtSplitter();
}
};
class PictureSplitterFactory: public SplitterFactory{
public:
virtual ISplitter* CreateSplitter(){
return new PictureSplitter();
}
};
class VideoSplitterFactory: public SplitterFactory{
public:
virtual ISplitter* CreateSplitter(){
return new VideoSplitter();
}
};
class MainForm : public Form
{
SplitterFactory* factory;//工厂
public:
MainForm(SplitterFactory* factory){
this->factory=factory;
}
void Button1_Click(){
ISplitter * splitter=
factory->CreateSplitter(); //多态new
splitter->split();
}
};
这种写法的好处是MainForm只需要从外界获得一个SplitterFactory类,然后由它来创建相应的splitter就好了。对MainForm来说,我不关心传进来的splitter到底是什么类型,我用就完了,这个是创建我的时候外边的那些组件要考虑的事。
当时看到这我不禁有些疑惑,这不是多此一举吗,你外边还得根据具体业务传具体的实际工厂啊!还有一个问题,我直接传一个splitter进来也可以吧,然后MainForm里边定义一个ISplitter来接收这个参数,后边也能用。
第一个问题,这不是多此一举,代码中的变化点根本不可能完全消除,工厂模式,乃至全部的设计模式都是为了把变化的点赶在一起,当要修改的时候只需要改很少的地方就行。工厂模式下,我只需要在外边更改工厂类型,MainForm里边的代码根本就改不了一点。不用工厂模式嘛,大家可以想一想,你得在MainForm里改多少东西。
第二个问题,还记得前文说的直接创建的问题吗?直接传splitter解决了其中一个问题,防止代码冗余,有些对象创建起来是麻烦,要好多步骤。但还有一个问题,你能确保这个对象一个够用吗?你只传一个进来的话(当然这个场景下是够用的),当你后边执行执行着发现,不行,我可能还得创建一个,要怎么办,再new?如果要再创建很多个呢?这不回到老问题上了。所以工厂模式,真的优雅!