创建型模式
创建型模式关注对象的创建过程,分离对象的创建和使用,让使用者无需关心创建细节,降低系统的耦合,不同的创建模式通过不同的方式回答3个问题:创建什么(what),由谁创建(who),何时创建(when)。
- 单例模式
- 简单工厂
- 工厂模式
- 抽象工厂
- 原型模式
- 建造者模式
单例模式
单例模式用于系统中独一无二的对象。
使用场景
- 需要确保某种类型的对象的唯一性,避免系统资源浪费,或避免多个对象之间不同步的问题,例如windows的任务管理器。
- 实际开发中,经常会把一个使用场景很多的数据对象做成单例,确实避免了数据不同步的问题,但是否存在破坏封装的问题?是不是只是为了偷懒滥用单例?有种全局变量满天飞的感觉。(这里确实存在疑问,有了解的朋友欢迎交流)
实现方式
单例的实现方式很多,是否考虑线程安全、饿汉、懒汉等。
总的原则如下:
- 禁止外部创建对象,即将构造函数的可见性改为private
- 在类内部创建并保存唯一实例,并将可见性设为private
- 通过一个公有静态方法访问变量
饿汉模式
单例对象在类加载时就创建,不存在线程安全问题,但可能会造成资源浪费。
class Singleton
{
public:
static Singleton* getInstance();
private:
Singleton(){};
static Singleton* ins_;
}
//初始化静态变量
Singleton* Singleton::ins_ = new Singleton();
Singleton* Singleton::getInstance()
{
return ins_;
}
懒汉模式
懒汉模式本身是线程不安全的,可能存在多个线程同时创建单例对象,因此需要线程同步。
- 常规写法,通过加锁实现线程之间的同步。
class Singleton
{
public:
static Singleton* getInstance();
private:
Singleton(){};
static Singleton* ins_;
static std::mutex mutex_;
}
//初始化
Singleton* Singleton::ins_ = nullptr;
std::mutex Singleton::mutex_;
Singleton* Singleton::getInstance()
{
if(ins_ == nullptr)
{
std::lock_guard<std::mutex> lock(mutex_);
if(ins_ == nullptr)
{
//防止多个线程在等待初始化变量
ins_ = new Singleton();
}
}
return ins_;
}
- 通过局部静态变量
class Singleton
{
public:
static Singleton* getInstance();
private:
Singleton(){};
}
Singleton* Singleton::getInstance()
{
//由于局部静态变量的初始化是线程安全的,所以不需要线程同步
static Singleton ins;
return ins;
}
资源释放问题
常规情况下,单例对象结束意味着程序结束,内核回收进程的逻辑内存,因此无需考虑回收问题。
但如果单例对象中存在其他资源,如数据库、文件等,需要主动释放,就需要考虑。
首先直接在析构函数中释放是不可取的,因为在析构函数中delete自身,会造成死循环,不断调用delete,如:
Singleton::~Singleton()
{
delete ins;
}
程序结束时,系统会释放所有类的静态成员变量,因此可以在单例类中创建一个内嵌类,通过该类的析构函数释放。
class Singleton
{
public:
static Singleton* getInstance();
private:
Singleton(){}
static Singleton* ins_;
//回收类
class GarbageCollector
{
public:
~GarbageCollector
{
delete ins_;
ins_ = nullptr;
//回收其他资源
doSomething();
}
}
//通过变量gc的回收
static GarbageCollector gc;
}
也可以通过注册atexit()函数或在单例类中提供主动释放的接口进行释放。
简单工厂模式
定义一个工厂类,根据参数不同返回不同的实例。
通过静态方法创建类实例。
优点:
- 分离对象的创建和使用
- 客户端不需要了解创建的细节
- 通过配置文件等方式,可以在不修改代码的情况下,修改产品类
缺点:
- 需要在工厂类中判断逻辑,增加或修改产品时需要修改工厂类,不符合开闭原则
- 使用静态方法,无法形成基于基层的等级结构
适用于工厂类负责创建的类型较少的场景。
工厂方法模式
不再使用同一个工厂创建所有产品,而是针对不同产品提供不同的工厂;
与简单工厂相比,引入了抽象工厂,具体工厂继承抽象工厂,实现具体的创建方法。
优点:
- 分离使用和创建
- 符合开闭原则
缺点:
- 类数量太多
- 如何判断使用哪个工厂?判断逻辑放在哪儿?
抽象工厂模式
创建一系列相关或互相依赖的产品,无需指定具体的类。
优点:
- 分离创建和使用
- 符合开闭原则
- 行为统一
缺点:
- 增加新的产品等级需要较大的修改(开闭原则倾向于产品族的增加)
原型模式(克隆)
对原型实例克隆来创建新的对象。
实际上就是深拷贝。
建造者模式
将复杂对象的表示和构建分离,使得同样的构建过程可以创建不同的表示。
强调构建过程。
主要在director类中实现构造的过程,在构建过程中还可以引入一些判断逻辑,实现精细的差异化构建。
优点:
- 分离使用和创建
- 开闭原则
- 可以精细的控制构建过程
缺点:
- 适用范围小