C++的设计模式

  1. 什么是设计模式
    指的是在特定环境下,人们解决某类重复出现问题的一套成功或有效的解决方案。
    大白话是:在一定环境下,使用固定的套路去解决问题。
  2. 作用:提高软件系统可维护性以及代码的可复用性。
  3. 原则的目的:高内聚低耦合
  4. 高内聚:一个类只做一件事
  5. 低耦合:类和类之间的关系越弱越好。
  6. 这样在后期代码某一部分出错时,只需要修改对应部分,而不需要修改大量和这类关系密切的其他类。减少工作量和出错的概率。
  7. 类的单一原则:类的职责单一,只对外提供一种功能
  8. 类的开闭原则:类的改动是通过增加代码实现的而不是通过修改代码实现的。
  9. 单例模式:分为懒汉式单例模式和饿汉式单例模式
    懒汉式单例模式:static 声明的变量在整个程序退出时释放,所谓的单例就是整个类只有一个全局对象,该对象使用static声明,变为类成员,并且构造函数被私有化,不能被外界随随便便的实例化,这个类成员在外部被赋予一个特殊值,才能声明这个唯一的对象。
    这里在类直接调用类属性(等于特殊值才可以,比如nullptr)instance时,才可以初始化,并且使用public的getInstance函数自动接收这个初始化的属性值,然后在这个函数中唯一的创建这个类的唯一对象。也就是唯一接口供外部使用
    优点是第一次调用的时候才初始化,避免内存浪费。缺点是必须加锁才能保证单例
#include <iostream>

using namespace std;

//懒汉式单例模式
class SingletonLazy {
private:
	static SingletonLazy* instance;
	// 构造函数私有化, 不让外界利用new创建实例
	SingletonLazy() {
		cout << "懒汉式单例模式\n";
	}
public:
	static SingletonLazy* getInstance() {
	//第一次引用时才被实例化,只有在外部被使用类名进行调用时才初始化我们的唯一对象,没有外部调用那么就不被初始化来占用内存。
		if (instance == nullptr) {
			instance = new SingletonLazy;
		}
		return instance;
	}
};

SingletonLazy* SingletonLazy::instance = nullptr;

//饿汉式单例模式
class SingletonHungry {
private:
	static SingletonHungry* instance2;
	SingletonHungry() {
		cout << "饿汉式单例模式\n";
	}
public:
	static SingletonHungry* getInstance() {
		return instance2;
	}
};
//private下的static变量虽然类外无法通过类直接访问,但是可以类外进行初始化
//加载时实例化,这里是类外对类内私有唯一对象 instance2进行初始化,其他在类外单独定义的对象不能被初始化,因为无法使用new SingletonHungry语句,也就是调用私有的构造函数。调用不了而对于类内唯一静态对象类内声明类外初始化符合原则,虽然类外初始化,但是使用范围还是类内,所以可以调用该类的私有构造函数对其进行初始化。
//不管后面是否调用函数,我们唯一的对象都被初始化了。
SingletonHungry* SingletonHungry::instance2 = new SingletonHungry;


int main() {
	//外部可以直接通过类方法getInstance直接调用获得该唯一的对象
	cout << SingletonHungry::getInstance << endl;
	cout << "action: \n";
	system("pause");
	return 0;
}

  1. 饿汉式单例模式:
    缺点:不管用不用,都会初始化,造成内存资源浪费
    优点:不需要加锁,执行效率高,线程安全的
  2. 策略模式
    策略模式:定义一系列的算法,把他们一个个封装起来,并且使他们可相互替换,具体实现与客户端完全分离,客户端只需要操作一个类就可以实现不同功能
    优点:1、减少了算法与使用算法之间的耦合度。 2、测试方便,每个算法都有自己的类,只要测试自己接口就行了,不影响其他算法
    每一个策略都是一个算法
#include <iostream>
#include <string>

using namespace std;
//策略抽象类,定义所有支持的算法的公共接口
class CashSuper {
public:
	virtual double acceptCash(double money) {
		return money;
	}
};
//具体策略类
class NormalFee :CashSuper {
public:
	double acceptCash(double money) {
		return money;
	}
};
class DiscountFee :CashSuper {
public:
	float discountNum;
public:
	DiscountFee(float discountNum) {
		this->discountNum = discountNum;
		cout << endl;
	}
	double acceptCash(double money) {
		return money * this->discountNum;
	}
};

class ReturnFee :CashSuper {
public:
	int fill;
	int send;
public:
	ReturnFee(int fill, int send) :fill(fill), send(send) {}
	double acceptCash(double money) {
		if (money > this->fill) {
			return money - send;
		}
		return money;
	}
};
//用一个具体策略来配置维护一个对策略对象的引用
CashContext 为具体算法和客户端之间的桥梁
//客户端可以根据不同的需求通过CashContext获得不同的结果
class CashContext {
private:
	CashSuper* cs = nullptr;
public:
	CashContext(int type) {
		switch (type) {
		case 0:
			cs = (CashSuper*) new NormalFee;
			break;
		case 1:
			cs = (CashSuper*)new DiscountFee(0.8);
			break;
		case 2:
			cs = (CashSuper*) new DiscountFee(0.7);
			break;
		case 3:
			cs = (CashSuper*) new DiscountFee(0.5);
			break;
		case 4:
			cs = (CashSuper*) new ReturnFee(300, 100);
			break;
		}
	}
	//根据不同策略对象来实现不同结果
	double getResult(double money) {
		return cs->acceptCash(money);
	}
};
int main()
{
	
	//实例化打八折类
	CashContext cc(1);
	//获取打折后金额
	double res = cc.getResult(100);
	cout << res << endl;
	return 0;
}

总结,如果将满减和打8折以及原价放一起(同一个类),假如打折或者原价代码出错,也会导致满减代码无法运行,也就无法实现满减功能,所以降低各个小功能之间的耦合度势在必行。,各个算法单独封装成一个个类,就是一个个不同的策略。

具体C++设计模式参考教程:https://blog.csdn.net/qq_46423987/article/details/126702565

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目 录 序言 前言 读者指南 第 1 章 引言 1 1.1 什么是设计模式 2 1.2 Smalltalk MVC 中的设计模式 3 1.3 描述设计模式 4 1.4 设计模式的编目 5 1.5 组织编目 7 1.6 设计模式怎样解决设计问题 8 1.6.1 寻找合适的对象 8 1.6.2 决定对象的粒度 9 1.6.3 指定对象接口 9 1.6.4 描述对象的实现 10 1.6.5 运用复用机制 13 1.6.6 关联运行时刻和编译时刻的结构 15 1.6.7 设计应支持变化 16 1.7 怎样选择设计模式 19 1.8 怎样使用设计模式 20 第 2 章 实例研究:设计一个文档编辑器 22 2.1 设计问题 23 2.2 文档结构 23 2.2.1 递归组合 24 2.2.2 图元 25 2.2.3 组合模式 272.3 格式化 27 2.3.1 封装格式化算法 27 2.3.2 Compositor 和 Composition 27 2.3.3 策略模式 29 2.4 修饰用户界面 29 2.4.1 透明围栏 29 2.4.2 Monoglyph 30 2.4.3 Decorator 模式 32 2.5 支持多种视感标准 32 2.5.1 对象创建的抽象 32 2.5.2 工厂类和产品类 33 2.5.3 Abstract Factory 模式 35 2.6 支持多种窗口系统 35 2.6.1 我们是否可以使用 Abstract Factory 模式 35 2.6.2 封装实现依赖关系 35 2.6.3 Window 和 WindowImp 37 2.6.4 Bridge 模式 40 2.7 用户操作 40 2.7.1 封装一个请求 41 2.7.2 Command 类及其子类 41 2.7.3 撤消和重做 42 2.7.4 命令历史记录 42 2.7.5 Command 模式 44 2.8 拼写检查和断字处理 44 2.8.1 访问分散的信息 44 2.8.2 封装访问和遍历 45 2.8.3 Iterator 类及其子类 46 2.8.4 Iterator 模式 48 2.8.5 遍历和遍历过程中的动作 48 2.8.6 封装分析 48 2.8.7 Visitor 类及其子类 51 2.8.8 Visitor 模式 52 2.9 小结 53 第 3 章 创建型模式 54 3.1 Abstract Factory(抽象工厂)—对象创建型模式 57 3.2 Builder(生成器)—对象创建型模式 633.3 Factory Method(工厂方法)—对象创建型模式 70 3.4 Prototype(原型)—对象创建型模式 87 3.5 Singleton(单件)—对象创建型模式 84 3.6 创建型模式的讨论 89 第 4 章 结构型模式 91 4.1 Adapter(适配器)—类对象结构型模式 92 4.2 Bridge(桥接)—对象结构型模式 100 4.3 Composite(组成)—对象结构型模式 107 4.4 Decorator(装饰)—对象结构型模式 115 4.5 FACADE(外观)—对象结构型模式 121 4.6 Flyweight(享元)—对象结构型模式 128 4.7 Proxy(代理)—对象结构型模式 137 4.8 结构型模式的讨论 144 4.8.1 Adapter 与 Bridge 144 4.8.2 Composite、 Decorator 与 Proxy 145 第 5 章 行为模式 147 5.1 CHAIN OF RESPONSIBIL ITY(职责链)—对象行为型模式 147 5.2 COMMAND(命令)—对象行为型模式 154 5.3 INTERPRETER(解释器)—类行为型模式 162 5.4 ITERATOR(迭代器)—对象行为型模式 171 5.5 MEDIATOR(中介者)—对象行为型模式 181 5.6 MEMENTO(备忘录)—对象行为型模式 188 5.7 OBSERVER(观察者)—对象行为型模式 194 5.8 STATE(状态)—对象行为型模式 201 5.9 STRATEGY(策略)—对象行为型模式 208 5.10 TEMPLATE METHOD(模板方法)—类行为型模式 214 5.11 VISITOR(访问者)—对象行为型模式 218 5.12 行为模式的讨论 228 5.12 1 封装变化 228 5.12.2 对象作为参数 228 5.12.3 通信应该被封装还是被分布 229 5.12.4 对发送者和接收者解耦 229 5.12.5 总结 231 第 6 章 结论 232 6.1 设计模式将带来什么 2326.2 一套通用的设计词汇 23

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值