设计模式-创建型模式

创建型模式

创建型模式关注对象的创建过程,分离对象的创建和使用,让使用者无需关心创建细节,降低系统的耦合,不同的创建模式通过不同的方式回答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类中实现构造的过程,在构建过程中还可以引入一些判断逻辑,实现精细的差异化构建。
优点:

  • 分离使用和创建
  • 开闭原则
  • 可以精细的控制构建过程

缺点:

  • 适用范围小
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值