工厂模式（Factory）——对象创建类、创建型模式

在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。

如何应对这种变化？如何绕过常规的对象创建方法(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？如果要再创建很多个呢？这不回到老问题上了。所以工厂模式，真的优雅！