文章目录
C++学习笔记——设计模式
视频链接
【系统开发】 C++系统工程师(入门到进阶/适合有一定基础)
P1 设计模式简介
-
理解松耦合设计思想
-
掌握面向对象设计原则
-
掌握重构技法改善设计
-
掌握GOF核心设计模式
-
《设计模式:可复用面向对象软件的基础》
-
从面向对象谈起:底层思维,抽象思维
- 向下:深入理解三大面向对象机制
- 封装,隐藏内部实现
- 继承,复用现有代码
- 多态,改写对象行为
- 向上:深刻把握面向对象机制带来的抽象意义,理解如何使用这些机制来表达现实世界,掌握什么是“好的面向对象设计”
- 向下:深入理解三大面向对象机制
-
软件设计复杂的根本原因:变化
-
如何解决复杂性:分解;抽象
-
软件设计的目标:复用
P2 面向对象设计原则
- 面向对象
- 隔离变化
- 各司其职:接口一样,实现不一样;强调各个类的责任
- 对象是什么
- 设计原则
- 依赖倒置原则:高层模块(稳定)不应该依赖于低层模块(变化),二者都应该依赖于抽象;抽象(稳定)不应依赖于实现细节(变化),实现细节应该依赖于抽象。
- 开放封闭原则:对扩展开放,对更改封闭;类模块应该是可扩展的,但是不可 修改。
- 单一职责原则:一个类应该仅有一个引起它变化的原因;变化的方向隐含着职责。
- Liskov替换原则:子类必须能够替换他们的基类;继承表达类型抽象。
- 接口隔离原则:不该强迫客户程序依赖他们不用的方法;接口应该小而完备。
- 优先使用对象组合,而不是继承
- 封装变化点:使用封装创建对象之间的分界层
- 针对接口编程,而不是针对实现编程:高内聚、低耦合
- 面向接口设计:行业强盛的标准:接口标准化
- 将设计原则提升为设计经验
- 设计习语:描述与特定语言相关的底层模式,技巧,习惯用法
- 设计模式:类与相互通信的对象之间的组织关系,包括角色、职责、协作方式等方面
- 架构模式:描述系统中与基本结构组织关系密切的高层模式,包括子系统划分,职责,以及如何组织它们之间关系的规则
P3 模板方法
- GOF-23种设计模式分类
- 从目的来看:创建型,结构型,行为型
- 从范围来看:类模式,处理类与子类的静态关系;对象模式,处理对象间的动态关系
- “组件协作”模式:框架与应用程序的划分,通过晚期绑定,实现框架与应用程序间的松耦合,是二者之间协作时常用的模式。
- 模板方法:早绑定 -> 晚绑定;定义一个操作中的算法的骨架(稳定),将一些步骤延迟到子类中。
- 设计模式:寻找稳定和变化的分离点。
P4 策略模式,Strategy
- “组件协作类”的模式
- “复用”:二进制级别的复用
- 策略模式:定义一系列算法,把它们一个个封装起来,并且使他们可互相替换(变化)。该模式使得算法可独立于使用它的客户程序(稳定)而变化(扩展,子类化)。
- 运行时切换算法
- 消除许多条件判断语句,解耦合,避免装载过多不必要的代码
- 如果Strategy对象没有实例变量,那么各个上下文可以共享同一个Strategy对象,节省对象开销
P5 观察者模式
- 动机:对象间的通知依赖关系
- 观察者模式:定义对象间的一种一对多(变化)的依赖关系,以便当一个对象的状态发生改变时,所有依赖它的对象都得到通知并自动更新。
P6装饰模式
- “单一职责”模式
- 动机:过度使用继承使扩展方式缺乏灵活性,随着子类的增多和组合,会导致更多子类的膨胀
- 装饰模式:通过组合而非继承的手法,实现了运行时动态扩展对象功能的能力,可以根据需要扩展多个功能,避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
P7桥模式
- “单一职责”模式
- 桥模式:将抽象部分(业务功能)与实现部分(平台实现)分离,使它们都可以独立变化。
- 要点:使用对象间的组合关系解耦了抽象与实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度变化,所谓变化,即“子类化”它们。
P8 工厂方法
- “对象创建”模式
- 工厂方法模式:定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法模式使得一个类的实例化延迟(目的:解耦;手段:虚函数)到子类。
P9 抽象工厂
- 动机:创建一系列相互依赖的对象
- 抽象工厂模式:提供一个接口,让该接口负责创建一系列“相关或相互依赖的对象”,无需指定它们具体的类。
P10 原型模式
- 动机:创建某些结构复杂的对象
- 原型模式:使用原型实例指定创建对象的种类,然后通过拷贝(深克隆)这些原型来创建新的对象。
P11 构建器
- 动机:复杂对象的创建工作
- 构建器模式:讲一个复杂对象的构建与其表示相分离,使得同样的构建过程(稳定)可以创建不同的表示(变化)。
P12 单例模式
- “对象性能”模式
- 动机:存在一些特殊类,在系统中只能存在一个实例
- 单例模式:保证一个类仅有一个实例,并提供一个该实例的全局访问点。
- 线程安全问题:
class Singleton
{
private:
static Singleton* instance;
private:
Singleton() {};//构造函数
~Singleton() {};//保留析构权利
Singleton(const Singleton&);//拷贝构造函数
Singleton& operator=(const Singleton&);//拷贝赋值函数
public:
static Singleton* getInstance();
};
// init static member
Singleton* Singleton::instance = NULL;
Singleton* Singleton::getInstance(){//没锁
if (m_instance == nullptr){
m_instance = new Singleton();
}
return m_instance;
}
Singleton* Singleton::getInstance(){//单检查锁,但读不需要锁,锁的消耗太大
Lock lock;
if (m_instance == nullptr){
m_instance = new Singleton();
}
return m_instance;
}
Singleton* Singleton::getInstance(){//双检查锁,但由于内存读写reorder不安全,编译器优化问题
if (m_instance == nullptr){//如果发生reorder,内存已分配,地址已赋值,但尚未调用构造器,此时另一个线程会认为m_instance已构造完成,导致出现问题。
Lock lock;
if (m_instance == nullptr){
m_instance = new Singleton();//理想顺序:先分配内存,再调用构造器,把内存地址赋给变量。有可能reorder:先分配内存,再把地址传给变量,最后调用构造器。
}
}
return m_instance;
}
class Singleton
{
private:
Singleton() { };
~Singleton() { };
Singleton(const Singleton&);
Singleton& operator=(const Singleton&);
public:
static Singleton& getInstance(){// C++11之后的最佳实践;C++11规定了local static在多线程条件下的初始化行为,要求编译器保证了内部静态变量的线程安全性。
static Singleton instance;
return instance;
}
};
// 还有很多复杂方法
P13 Flyweight,享元模式
- 动机:大量细粒度对象很快充斥在系统中,带来很高的运行时代价。
- 享元模式:运用共享技术有效地支持大量细粒度的对象。
P14 门面模式
- “接口隔离”模式:组件构建过程中,某些接口之间直接的依赖常常会带来很多问题、甚至无法实现,采用添加一层间接(稳定)接口,来隔离本来相互紧密关联的接口是一种常见的解决方案。
- 门面模式:为子系统中的一组接口提供一个一致(稳定)的界面,门面模式定义了一个高层接口,这个接口使得这一子系统更加容易使用(复用)。
P15 代理模式
- “接口隔离”模式
- 动机:在面向对象系统中,有些对象由于某种原因(比如对象创建开销很大,或者 某些操作需要安全控制,或者需要进程外的访问等),直接访问会给使用者、或者系统结构带来很多麻烦。
- 代理模式:为其它对象提供一种代理以控制(隔离,使用接口)对这个对象的访问。
- copy on write:读取时共享对象,修改时才创建新对象
P16 适配器
- 动机:将一些现存的对象放在新的环境中应用,但是新环境要求的接口是这些现有对象所不满足的。
- 适配器模式:将一个类的接口转换成客户希望的另一个接口。适配器模式使得原本由于接口不兼容而不能在一起工作的那些类可以一起工作。
P17 中介者
- 动机:多个对象互相关联交互,对象之间维持复杂引用关系,如果一些需求改变,这种直接的引用关系将面临不断的变化。
- 中介者模式:用一个中介对象来封装(封装变化)一系列的对象交互。中介者使各对象不需要显式的相互引用(编译时依赖->运行时依赖),从而使其耦合松散(管理变化),而且可以独立地改变它们之间的交互。
- 门面模式是系统间(单向)的,中介者模式是系统内(双向)的。
P18 状态模式
- “状态变化”模式:在组件构建中,某些对象的状态经常面临变化,如何对这些变化进行有效的管理,同时又维持高层模块的稳定?
- 动机:状态不同,行为也会发生改变
- 状态模式:允许一个对象在其内部状态改变时改变它的行为,从而使对象看起来似乎修改了其行为。
P19 备忘录模式
- 动机:某些对象的状态在转换过程中,可能要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态,便会暴露对象的细节实现。
- 备忘录模式:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,这样以后就可以将该对象恢复到原先保存的状态。
- 核心:信息隐藏
- 已过时,有序列化替代
P20 组合模式 //树形结构
- “数据结构”模式:组件内存在特定的数据结构,将这些特定数据结构封装在内部,在外部提供统一的接口,实现与特定数据结构无关的访问。
- 组合模式:将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性(稳定)。
P21 迭代器模式
- 动机:集合对象内部结构常常变化各异,我们不希望暴露这些集合对象的内部结构,让外部客户代码透明地访问其中包含的元素;同时这种“透明遍历”也为同一种算法在多种集合对象上进行操作提供了可能。
- 迭代器模式:提供一种方法顺序访问一个聚合对象中的各个元素,而不暴露(稳定)该对象的内部表示。
P22 职责链模式 //单链表结构
- 动机:一个请求可能被多个对象处理,但是每个请求在运行时只能有一个接收者,如果显式指定,将必不可少地带来请求者与接收者的紧耦合。
- 职责链模式:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递请求,直到有一个对象处理它为止。
- 很少用
P23 命令模式
- “行为变化”模式:组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式将组件的行为和组件本身进行解耦,从而支持组件行为的变化,实现两者之间的松耦合。
- 命令模式:将一个请求(行为)封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。
- C++中追求性能,用函数对象代替
- 设计模式是为弥补语言不足而准备。
P24 访问器模式
- 访问器模式:表示一个作用于某对象结构中的各元素的操作,使得可以在不改变(稳定)各元素的类的前提下定义(扩展)作用于这些元素的新操作(变化)。
P25 解析器模式
- “领域规则”模式
P26 设计模式总结
- 目标:管理变化,提高复用
- 两种手段:分解 vs 抽象
- 八大原则
- 重构技法
- 良好的设计模式是演化的结果