“对象创建”模式
通过“对象创建”模式绕开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