c++设计模式 讲解

C++单例模式是一种用于限制特定类只能创建一个实例的设计模式。在实际应用中，有时候会遇到需要对单例模式进行继承的情况。本文将围绕这一主题，探讨C++单例被继承的案例及使用场景。

一、C++单例模式简介

1.1 单例模式概述

单例模式是设计模式中的一种，它保证一个类仅有一个实例，并提供一个全局访问点。这种模式在需要频繁创建和销毁对象的情况下，可以提高性能。

1.2 C++中的单例模式实现

在C++中，常见的单例模式实现方式包括静态成员变量、静态指针和智能指针等。其中静态成员变量是最常见的实现方式之一。

1.3 单例模式的使用场景

单例模式适用于需要全局访问点的场景，例如日志系统、数据库连接池等。单例模式还可以用来确保系统中某个类的实例只能存在一个，保证数据一致性。

二、C++单例被继承的案例

2.1 基类单例模式

在某些情况下，我们可能需要对一个基类的单例进行继承。我们有一个基类A，需要确保只有一个实例存在。有一个派生类B，也需要保证只有一个实例存在，且该实例与基类A的实例相同。

2.2 实现方式

实现基类单例模式被继承的关键在于，派生类的实例需要依赖基类的实例。可以通过将基类构造函数设置为私有，并在派生类的构造函数中调用基类的构造函数来实现。

2.3 案例分析

假设我们有一个基类SingletonBase和一个派生类SingletonDerived，它们都需要保证只有一个实例存在。我们可以通过在派生类的构造函数中调用基类的构造函数来实现这一点。

三、C++单例被继承的使用场景

3.1 多层次的对象关系

在多层次的对象关系中，有时候需要保证每一层的对象都只有一个实例存在。此时，单例被继承可以很好地满足这一需求。

3.2 多态对象的统一管理

在某些情况下，我们希望对不同类型的对象进行统一管理，并确保每种类型的对象都只有一个实例存在。这时，单例被继承可以帮助我们实现这一目标。

3.3 维护对象间的一致性 在面向对象的设计中，对象之间往往存在一定的关联关系。通过单例被继承，我们可以确保相关对象的一致性，从而提高系统的稳定性和可靠性。

⼤话设计模式——C++版本

⼀、什么是设计模式

设计模式（Design pattern）是⼀套被反复使⽤、多数⼈知晓的、经过分类编⽬的、代码设计经验的总结。使⽤设计模式是为了可重⽤代

码、让代码更容易被他⼈理解、保证代码可靠性。 毫⽆疑问，设计模式于⼰于他⼈于系统都是多赢的，设计模式使代码编制真正⼯程化，设

计模式是软件⼯程的基⽯，如同⼤厦的⼀块块砖⽯⼀样。项⽬中合理的运⽤设计模式可以完美的解决很多问题，每种模式在现在中都有相应

的原理来与之对应，每⼀个模式描述了⼀个在我们周围不断重复发⽣的问题，以及该问题的核⼼解决⽅案，这也是它能被⼴泛应⽤的原因。

简单说：

模式：在某些场景下，针对某类问题的某种通⽤的解决⽅案。

场景：项⽬所在的环境

问题：约束条件，项⽬⽬标等

解决⽅案：通⽤、可复⽤的设计，解决约束达到⽬标。

⼆、设计模式的三个分类

创建型模式：对象实例化的模式，创建型模式⽤于解耦对象的实例化过程。

结构型模式：把类或对象结合在⼀起形成⼀个更⼤的结构。

⾏为型模式：类和对象如何交互，及划分责任和算法。

如下图所⽰：

三、各分类中模式的关键点

四、概说23种设计模式

1.单例模式

单例模式，它的定义就是确保某⼀个类只有⼀个实例，并且提供⼀个全局访问点。

单例模式具备典型的3个特点：1、只有⼀个实例。 2、⾃我实例化。 3、提供全局访问点。

因此当系统中只需要⼀个实例对象或者系统中只允许⼀个公共访问点，除了这个公共访问点外，不能通过其他访问点访问该实例时，可以使

⽤单例模式。

单例模式的主要优点就是节约系统资源、提⾼了系统效率，同时也能够严格控制客户对它的访问。也许就是因为系统中只有⼀个实例，这样

就导致了单例类的职责过重，违背了“单⼀职责原则”，同时也没有抽象类，所以扩展起来有⼀定的困难。其UML结构图⾮常简单，就只有⼀

个类，如下图：

2.⼯⼚⽅法模式

作为抽象⼯⼚模式的孪⽣兄弟，⼯⼚⽅法模式定义了⼀个创建对象的接⼝，但由⼦类决定要实例化的类是哪⼀个，也就是说⼯⼚⽅法模式让

C++设计模式——状态模式State

动机(Motivation)对象状态如果改变，其⾏为也会随之⽽发⽣变化，⽐如⽂档处于只读状态，其⽀持的⾏为和读写状态⽀持的⾏为就可能完全不同。

如何在运⾏时根据对象的状态来透明地改变对象的⾏为？

模式定义

允许⼀个对象在其内部状态改变时改变它的⾏为。从⽽使对象看起来似乎修改了其⾏为。 ——《设计模式》GoF

状态模型，就是当⼀个对象的内在状态改变时允许改变其⾏为，这个对象看起来像是改变了其类。状态模式主要解决的是当控制⼀个对象状

态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表⽰不同状态的⼀系列类当中，可以把复杂的判断逻辑简化。

要点总结

State模式将所有与⼀个特定状态相关的⾏为都放⼊⼀个State的⼦对象中，在对象状态切换时，切换相应的对象； 但同时维持State的接⼝，这样实现了具体操作与状态转换之间的解耦。转换是原⼦性的

与Strategy模式类似

结构（Structure）

看着这个类图好像和策略模式的UML图似乎相同？

确实是这样的，这两种模式在结构上是相同的，但意图却完全不⼀样，策略模式是让⽤户指定更换的策略算法，⽽状态模式是状态在满⾜⼀定条件下的⾃动更换，⽤户⽆法指定状态，最多只能设置初始状态。

这⾥解释还是有点抽象，我在知乎上找到了⼀个⽣动形象的例⼦，虽然有点污，但话糙理不糙，⼤家可以看⼀下。

基本代码

#include

using namespace std;

class Context;

class State { // 抽象状态类，定义⼀个接⼝以封装与Context的⼀个特定状态相关的⾏为

public:

virtual void Handle(Context* c) = 0;

virtual ~State() {}

};

class Context { // 维护⼀个ConcreteState⼦类的实例，这个实例定义为当前状态

private:

State* state;

C++设计模式

一、功能

将一个类的接口转换成客户希望的另外一个接口，解决两个已有接口之间不匹配的问题。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

二、结构图

(1)class adapter

(2)object adapter

三、实现

和其他很多模式一样，学习设计模式的重点是学习每种模式的思想，而不应拘泥于它的某种具体结构图和实现。因为模式是灵活的，其实现可以是千变万化的，只是所谓万变不离其宗。 在STL中大量运用了Adapter模式，象function adapter、iterator adpter，它们与这里说的adapter结构并不一样，但思想是一样的。具体的介绍可到侯捷网站上找相关文章，他讲得非常好。

四、示例代码

(1)class adapter

namespace DesignPattern_Adapter

{

// class Adaptee

class Adaptee

{

public:

void SpecialRequest() {}

} ;

// class Target

class Target

{

public:

virtual void Request() = 0 ;

} ;

// class Adapter

class Adapter : public Target, private Adaptee

{

public:

virtual void Request() { SpecialRequest() ; }

} ;

}

客户端代码：

{

using namespace DesignPattern_Adapter ;

Target *p = new Adapter() ;

p->Request() ; //实际上调用的是Adaptee::SpecialRequest()

}

(2)object adapter namespace DesignPattern_Adapter