工厂方法模式

“对象创建”模式

通过“对象创建”模式绕开new,来避免对象创建(new)过程中所导致的紧耦合(依赖具体类),从而支持对象创建的稳定。它是接口抽象之后的第一部工作。

典型模式有

  • Factory Method
  • Abstract Factory
  • Prototype
  • Builder
  • Singleton

动机

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

那么就出现了一些问题:如何应对这种变化?如何绕过常规的对象创建的对象方法(new),提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合?

class FileSpilter{
public:
    void split(){
        //....
    }
};

int main(){
    FileSpilter *splitter = new FileSpilter(filePath, number);
    splitter->split();
}

假设上面这段代码是为了实现一个文件分割的功能

这是一个非常简单的对象使用模式,那么它有什么问题呢?

目前看来好像是没有什么问题,我们需要在一个变化的场景中看问题,看到它未来变化的需求。根据面向接口的设计原则,那么我们就要去做一个抽象类(接口)。面向接口的编程告诉我们,一个对象的类型往往应该声明成接口或抽象类,而不应该声明成具体的类。

因此如果我们之后要实现对于二进制、文本文件爱你、图片以及视屏文件等……的分割的时候,我们可以想到去声明一个分割的抽象类。

class ISplitter
{
public:
    virtual void split() = 0;
    //....
    virtual ~ISplitter() {}
};
class BinarySpiltter : public ISplitter
{
};

class TxtSplitter : public ISplitter
{
};

class PictureSplitter : public ISplitter
{
};

class VideoSplitter : public ISplitter
{
};
class Main
{
    

public:
    
    void method1()
    {
       ISplitter *splitter = 
          new TxtSplitter(filePath, number); //依赖具体类
    splitter->split();
    }
}

面向接口编程最简单的表现形式就是变量要声明成抽象基类。

那么我们为什么要实现面向接口编程呢?根据设计模式的依赖倒置原则:应该依赖抽象,不应该依赖实现细节。

ISplitter *splitter = new TxtSplitter(filePath, number);

上面这行代码等号的左边是抽象依赖,而右边是细节依赖,那么在编译时总体还是要依赖TxtSplitter();属于编译时的细节依赖,违背了依赖倒置原则。

那么该怎么实现呢?总不可能去new一个接口吧。

我们回顾一下对象创建模式的目标:绕开new,来避免对象创建(new)过程中所导致的紧耦合。

不能用new,那么我们该怎么做呢?

看看下面这个实现

class SplitterFactory{
    public:
    ISplitter* CreateSplitter(){
        return new TxtSplitter(filePath, number);
    }
};

class ISplitter
{
public:
    virtual void split() = 0;
    //....
    virtual ~ISplitter() {}
};
class BinarySpiltter : public ISplitter
{
};

class TxtSplitter : public ISplitter
{
};

class PictureSplitter : public ISplitter
{
};

class VideoSplitter : public ISplitter
{
};
class Main
{
public:
    
    void method1()
    {
        SplitterFactory* factory;
        ISplitter *splitter = factory->CreateSplitter();
        splitter->split();
    }
}

这么做貌似是改善了一些,但是问题依然没有解决,main()最终还是要依赖TxtSplitter,只不过是绕了一层。还是没有解决。

我们来回顾以下,c++在运行时依赖是怎么实现的?自然是虚函数了。

class ISplitter
{
public:
    virtual void split() = 0;
    //....
    virtual ~ISplitter() {}
};

class SplitterFactory{
public:
    virtual ISplitter* CreateSplitter()=0;
    
    virtual ~SplitterFactory(){

    }
};

class BinarySpiltter : public ISplitter
{
};

class TxtSplitter : public ISplitter
{
};

class PictureSplitter : public ISplitter
{
};

class VideoSplitter : public ISplitter
{
};

class Main
{
public:
    
    void method1()
    {
        SplitterFactory* factory;
        ISplitter *splitter = factory->CreateSplitter();
        splitter->split();
    }
}

利用c++的多态,我们把真正创建对象交给未来,也就是SplitterFactory,进行运行时创建

//抽象类
class ISplitter
{
public:
    virtual void split() = 0;
    //....
    virtual ~ISplitter() {}
};
//工厂基类
class SplitterFactory
{
public:
    virtual ISplitter *CreateSplitter() = 0;

    virtual ~SplitterFactory()
    {
    }
};
class BinarySpiltter : public ISplitter
{
};

class TxtSplitter : public ISplitter
{
};

class PictureSplitter : public ISplitter
{
};

class VideoSplitter : public ISplitter
{
};
class BinarySpiltterFactory : public SplitterFactory
{
public:
    ISplitter *CreateSplitter()
    {
        return new BinarySpiltter();
    }
};
class TxtSpiltterFactory : public SplitterFactory
{
public:
    ISplitter *CreateSplitter()
    {
        return new TxtSpiltter();
    }
};
class PictureSpiltterFactory : public SplitterFactory
{
public:
    ISplitter *CreateSplitter()
    {
        return new PictureSpiltter();
    }
};
class VideoSpiltterFactory : public SplitterFactory
{
public:
    ISplitter *CreateSplitter()
    {
        return new VideoSpiltter();
    }
};
class Main
{
    ISplitter *factory;

public:
    Main(SplitterFactory *factory)
    {
        this->factory = factory;
    }
    void method1()
    {
        ISplitter *splitter = factory->CreateSplitter(); //多态new
        splitter->split();
    }
}

我们可以看到,每一个具体的类都有一个对应的工厂,但是实现时,我们只需要创建一个工厂。通过这样的改良后,Main不依赖具体类。

松耦合并不是把变化给消灭掉,而实际上是将它放在一个局部的地方。

现在来总结一下:

  • Factory Method 模式用于隔离对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型,紧耦合关系(new)会导致软件的脆弱。
  • Factory Method模式通过面向对象的手法,将所要创建的具体对象工作延迟到子类,从而实现一种扩展(而非更改)的策略,较好地解决了这种紧耦合关系。
  • Factory Method模式解决“单个对象”的需求变化。缺点在于要求创建方法/参数相同。

定义一个用于创建对象的接口,让字类决定实例化哪一个类。Factory Method使得一个类的实例化延迟(目的:解耦,手段:虚函数)到子类。

———《设计模式》GoF

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值