C++-设计模式-基础

本文详细介绍了C++设计模式的基础,包括设计模式的概念、意义、分类和基本设计原则。文章强调了设计模式在软件工程中的重要性,提供了解决问题的通用套路。文章深入探讨了开放关闭原则、依赖倒转原则、里氏代换原则和单一职责原则等核心原则,阐述了它们在实际编程中的应用,旨在帮助开发者理解和应用这些设计模式,提升代码的可重用性和可维护性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

C++设计模式编程基础

一、前言

1.1模式

在一定环境中解决某一问题的方案,包括三个基本元素–问题,解决方案和环境。
​ 大白话:在一定环境下,用固定套路解决问题。

要素名特点
模式名模式是一个有意义的名称,简介描述模式本质
问题描述特定的问题,确定在合适使用模式,解释了 设计问题和问题存在的前因后果
解决方案解决方案包括设计的组成成分 和职责, 相互关系及写作方式,描述静态关系和动态规划
如何得到所需要的结果
效果应用模式后的效果、 系统状态或配置 、使用模式带来的后果和应权衡的问题等
1.2设计模式(Design pattern)

是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代 码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的;设计模式使代码编制真正工程化;
设计模式是软件工程的基石脉络,如同大厦的结构一样。
根据模式作用于类还是作用于对象来划分,可以分为类模式和对象模式
(1)类模式:该模式用于处理类与子类之间的关系。这种关系通过继承建立,编译时就已经确定静态的,属于类模式的有工厂模式、适配器模式、模板模式、解释器模式。
​ (2)对象模式:该模式用于处理类与类之间的关系。这种关系通过组合或聚合实现,是动态,除了类模式的4种,其他都属于对象模式。

1.3学习设计模式的意义

提高职业素养,关注学员在行业内的长期发展。

“我眼中的设计模式”
把简单的问题复杂化(标准化),把环境中的各个部分进行抽象、归纳、解耦合。
​ 不是多神秘的东西,我们初学者也能学的会。要有信心。
学习设计模式的方法
​ 对初学者:
​ 积累案例,大于背类图。
​ 初级开发人员:
​ 多思考、多梳理,归纳总结;
​ 尊重事物的认知规律,注意事物临界点的突破。不可浮躁。
​ 中级开发人员
​ 合适的开发环境,寻找合适的设计模式,解决问题。
​ 多应用
​ 对经典组合设计模式的大量、自由的运用。要不断的追求。

1.4 设计模式的分类

Gang of Four的“Design Patterns: Elements of Resualbel Software”书将设计模式归纳为三大类型,共23种。
创建型模式 : 通常和对象的创建有关,涉及到对象实例化的方式。(共5种模式)
结构型模式: 描述的是如何组合类和对象以获得更大的结构。(共7种模式)
行为型模式: 用来对类或对象怎样交互和怎样分配职责进行描述。(共11种模式)
创建型模式用来处理对象的创建过程,主要包含以下5****种设计模式:
1,工厂方法模式(Factory Method Pattern)的用意是定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类中。
2,抽象工厂模式(Abstract Factory Pattern)的意图是提供一个创建一系列相关或者相互依赖的接口,而无需指定它们具体的类。
3,建造者模式(Builder Pattern)的意图是将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。
4,原型模式(Prototype Pattern)是用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。
5,单例模式(Singleton Pattern)是保证一个类仅有一个实例,并提供一个访问它的全局访问点。
结构型模式用来处理类或者对象的组合,主要包含以下7****种设计模式:
6,[代理模式])(Proxy Pattern)就是为其他对象提供一种代理以控制对这个对象的访问。
7,装饰者模式(Decorator Pattern)动态的给一个对象添加一些额外的职责。就增加功能来说,此模式比生成子类更为灵活。
8,适配器模式(Adapter Pattern)是将一个类的接口转换成客户希望的另外一个接口。使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
9,桥接模式(Bridge Pattern)是将抽象部分与实际部分分离,使它们都可以独立的变化。
10,组合模式(Composite Pattern)是将对象组合成树形结构以表示“部分–整体”的层次结构。使得用户对单个对象和组合对象的使用具有一致性。
11,外观模式(Facade Pattern)是为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
12,享元模式(Flyweight Pattern)是以共享的方式高效的支持大量的细粒度的对象。
行为型模式用来对类或对象怎样交互和怎样分配职责进行描述,主要包含以下11****种设计模式:
13,模板方法模式(Template Method Pattern)使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
14,命令模式(Command Pattern)是将一个请求封装为一个对象,从而使你可用不同的请求对客户端进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。
15,责任链模式(Chain of Responsibility Pattern),在该模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求,这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。
16,策略模式(Strategy Pattern)就是准备一组算法,并将每一个算法封装起来,使得它们可以互换。
17,中介者模式(Mediator Pattern)就是定义一个中介对象来封装系列对象之间的交互。终结者使各个对象不需要显示的相互调用 ,从而使其耦合性松散,而且可以独立的改变他们之间的交互。
18,观察者模式(Observer Pattern)定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。
19,备忘录模式(Memento Pattern)是在不破坏封装的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。
20,访问者模式(Visitor Pattern)就是表示一个作用于某对象结构中的各元素的操作,它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
21,状态模式(State Pattern)就是对象的行为,依赖于它所处的状态。
22,解释器模式(Interpreter Pattern)就是描述了如何为简单的语言定义一个语法,如何在该语言中表示一个句子,以及如何解释这些句子。
23,迭代器模式(Iterator Pattern)是提供了一种方法顺序来访问一个聚合对象中的各个元素,而又不需要暴露该对象的内部表示。

二、设计模式基本原则

最终目的:高内聚,低耦合

  1. 开放封闭原则 (OCP,Open For Extension, Closed For Modification Principle)
    类的改动是通过增加代码进行的,而不是修改源代码。
  2. 单一职责原则 (SRP,Single Responsibility Principle)
    类的职责要单一,对外只提供一种功能,而引起类变化的原因都应该只有一个。
  3. 依赖倒置原则 (DIP,Dependence Inversion Principle)
    依赖于抽象(接口),不要依赖具体的实现(类),也就是针对接口编程。
  4. 接口隔离原则 (ISP,Interface Segegation Principle)
    不应该强迫客户的程序依赖他们不需要的接口方法。一个接口应该只提供一种对外功能,不应该把所有操作都封装到一个接口中去。
  5. 里氏替换原则 (LSP, Liskov Substitution Principle)
    任何抽象类出现的地方都可以用他的实现类进行替换。实际就是虚拟机制,语言级别实现面向对象功能。
  6. 优先使用组合而不是继承原则(CARP,Composite/Aggregate Reuse Principle)
    如果使用继承,会导致父类的任何变换都可能影响到子类的行为。
    如果使用对象组合,就降低了这种依赖关系。
  7. 迪米特法则(LOD,Law of Demeter)
    一个对象应当对其他对象尽可能少的了解,从而降低各个对象之间的耦合,提高系统的可维护性。例如在一个程序中,各个模块之间相互调用时,通常会提供一个统一的接口来实现。这样其他模块不需要了解另外一个模块的内部实现细节,这样当一个模块内部的实现发生改变时,不会影响其他模块的使用。(黑盒原理)
    案例图
    开闭原则案例
    在这里插入图片描述
    依赖倒转
    1)
    在这里插入图片描述

在这里插入图片描述

2)
在这里插入图片描述

迪米特法则

1)和陌生人说话

在这里插入图片描述

2)不和陌生人说话

在这里插入图片描述

  1. 与依赖倒转原则结合 某人和 抽象陌生人说话 让某人和陌生人进行解耦合

943615)]

二 、开放关闭原则

1.开闭原则定义 :

一个软件实体应当对扩展开放,对修改关闭。也就是说在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,即实现在不修改源代码的情况下改变这个模块的行为。

2.开闭原则分析:

(1)开闭原则由Bertrand Meyer于1988年提出,它是面向对象设计中最重要的原则之一。
(2)在开闭原则的定义中,软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。
(3)抽象化是开闭原则的关键。
(4)开闭原则还可以通过一个更加具体的“对可变性封装原则”来描述,对可变性封装原则(Principle of Encapsulation of Variation,EVP)要求找到系统的可变因素并将其封装起来。

3.开闭原则实例:

某图形界面系统提供了各种不同形状的按钮,客户端代码可针对这些按钮进行编程,用户可能会改变需求要求使用不同的按钮,原始设计方案如图所示:

在这里插入图片描述

现对该系统进行重构,使之满足开闭原则的要求。

在这里插入图片描述

4.图一和图二对比分析

图(1):客户端的一个方法直接调用加法类,但是我想添加一个减法类,你就会发现添加减法类就得改变加法类中代码(用switch语句实现),这就违背了“开闭原则”,于是我们就应该重新重构。
如图(2)在这个图中我们添加了一个运算类的父类,这样我们再添加减法类的时候就不用修改客户端类。

三、依赖倒转原则

  1. 1.依赖倒转原则定义

    ​ i. 高层模块不应该依赖低层模块,它们都应该依赖抽象。抽象不应该依赖于细节,细节应该依赖于抽象。

    ​ ii. 要针对接口编程,不要针对实现编程。

2. 依赖倒转原则分析

a) 简单来说,依赖倒转原则就是指:代码要依赖于抽象的类,而不要依赖于具体的类;要针对接口或抽象类编程,而不是针对具体类编程。
b) 实现开闭原则的关键是抽象化,并且从抽象化导出具体化实现,如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要手段。
c) 依赖倒转原则的常用实现方式之一是在代码中使用抽象类,而将具体类放在配置文件中。
d) 类之间的耦合 1.零耦合关系 2.具体耦合关系 3.抽象耦合关系。 依赖倒转原则要求客户端依赖于抽象耦合,以抽象方式耦合是依赖倒转原则的关键。
e) 依赖注入:
构造注入:通过构造函数注入实例变量
设值注入:通过Setter方法注入实例变量
接口注入:通过接口方法注入实例变量

3. 依赖倒转原则实例

某系统提供一个数据转换模块,可以将来自不同数据源的数据转换成多种格式,如可以转换来自数据库的数据(DatabaseSource)、也可以转换来自文本文件的数据(TextSource),转换后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)
​ ​ 在这里插入图片描述

​ ​ 在这里插入图片描述
### 图(一)和图(二)分析:
图(一)为什么要到图(二)哪?因为该系统可能需要增加新的数据源或者新的文件格式,每增加一个新的类型的数据源或者新的类型的文件格式,客户类MainClass都需要修改源代码,以便使用新的类,但违背了开闭原则。现使用依赖倒转原则对其进行重构。
### 总结:
高层模块不应该依赖底层模块,两个都应该依赖与抽象;抽象不应该依赖于细节,细节应该依赖于抽象。

四、里氏代换原则

1.定义

i. 如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有变化,那么类型S是类型T的子类型。

ii. 所有引用基类(父类)的地方必须能透明地使用其子类的对象。
.### 2.分析

​ i. 在软件中如果能够使用基类对象,那么一定能够使用其子类对象。把基类都替换成它的子类,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类的话,那么它不一定能够使用基类。

​ ii. 里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象。

3.实例

某系统需要实现对重要数据(如用户密码)的加密处理,在数据操作类(DataOperator)中需要调用加密类中定义的加密算法,系统提供了两个不同的加密类,CipherA和CipherB,它们实现不同的加密方法,在DataOperator中可以选择其中的一个实现加密操作。如图所示:

​ ​ 在这里插入图片描述

​ ​ 在这里插入图片描述

###4. 图(一)和图(二)分析:
图(一)为什到图(二)哪?因为如果需要更换一个加密算法类或者增加并使用一个新的加密算法类,如将CipherA改为CipherB,则需要修改客户类Client和数据操作类DataOperator的源代码,违背了开闭原则。现使用里氏代换原则对其进行重构,使得系统可以灵活扩展,符合开闭原则。

5.总结:

子类型必须能够替换掉它们的父类型。

五、单一职责原则

1. 定义

 i.  一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。

 ii. 就一个类而言,应该仅有一个引起它变化的原因。 

2. 分析

i. 一个类(或者大到模块,小到方法)承担的职责越多,它被复用的可能性越小,而且如果一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作。

ii.类的职责主要包括两个方面:数据职责和行为职责,数据职责通过其属性来体现,而行为职责通过其方法来体现。

iii.单一职责原则是实现高内聚、低耦合的指导方针,在很多代码重构手法中都能找到它的存在,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

###3. 实例

i. 某基于Java的C/S系统的“登录功能”通过如下登录类(Login)实现:

​ ​ 在这里插入图片描述

​ 图(一)

​ ​ 在这里插入图片描述

​ 图(二)

4.图一和图二有什么区别哪?

图(一)功能太过于集成,严重违反类的单一原则。

5.总结:

就一个类而言,应该仅有一个引起它变化的原因。
上接:程序员必备的七大面向对象设计原则(一)
下接:程序员必备的七大面向对象设计原则(三)

六、接口隔离原则

1. 定义

i. 客户端不应该依赖那些它不需要的接口。

ii. 一旦一个接口太大,则需要将它分割成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可。

2.分析

​ i. 接口隔离原则是指使用多个专门的接口,而不使用单一的总接口。每一个接口应该承担一种相对独立的角色,不多不少,不干不该干的事,该干的事都要干。

​ ii. 使用接口隔离原则拆分接口时,首先必须满足单一职责原则,将一组相关的操作定义在一个接口中,且在满足高内聚的前提下,接口中的方法越少越好。

​ iii. 可以在进行系统设计时采用定制服务的方式,即为不同的客户端提供宽窄不同的接口,只提供用户需要的行为,而隐藏用户不需要的行为

3.实例

​ i. 下图展示了一个拥有多个客户类的系统,在系统中定义了一个巨大的接口(胖接口)AbstractService来服务所有的客户类。如图所示:
​ ​ ​ ​ ​ ​ 在这里插入图片描述

​ ​ 在这里插入图片描述

4.图(一)和图(二)分析:

​ 图(一)为什么到图(二)哪?因为这样做既满足了接口隔离原则,又满足了单一原则,何乐而不为呢,但是也带来了很多的不便,类增多了。

5.总结:

​ 类应该完全依赖相应的专门的接口

七、合成复用原则

1.定义

​ i. 尽量使用对象组合,而不是继承来达到复用的目的。

2.分析

​ i. 合成复用原则就是指在一个新的对象里通过关联关系(包括组合关系和聚合关系)来使用一些已有的对象,使之成为新对象的一部分;新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之:要尽量使用组合/聚合关系,少用继承。

​ ii. 在面向对象设计中,可以通过两种基本方法在不同的环境中复用已有的设计和实现,即通过组合/聚合关系或通过继承。

a) 继承复用:实现简单,易于扩展。破坏系统的封装性;从基类继承而来的实现是静态的,不可能在运行时发生改变,没有足够的灵活性;只能在有限的环境中使用。(“白箱”复用 )

b) 组合/聚合复用:耦合度相对较低,选择性地调用成员对象的操作;可以在运行时动态进行。(“黑箱”复用 )

​ iii. 组合/聚合可以使系统更加灵活,类与类之间的耦合度降低,一个类的变化对其他类造成的影响相对较少,因此一般首选使用组合/聚合来实现复用;其次才考虑继承,在使用继承时,需要严格遵循里氏代换原则,有效使用继承会有助于对问题的理解,降低复杂度,而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度,因此需要慎重使用继承复用。
​ ​ 在这里插入图片描述

3.实例

i. 某教学管理系统部分数据库访问类设计如图所示:

​ ​ ​ ​ 在这里插入图片描述

4.图(一)和图(二)分析:

图(一)为什么到图(二)哪?因为如果需要更换数据库连接方式,如原来采用JDBC连接数据库,现在采用数据库连接池连接,则需要修改DBUtil类源代码。如果StudentDAO采用JDBC连接,但是TeacherDAO采用连接池连接,则需要增加一个新的DBUtil类,并修改StudentDAO或TeacherDAO的源代码,使之继承新的数据库连接类,这将违背开闭原则,系统扩展性较差。

5.总结:

类中应用,尽量使用对象组合而不是用继承来达到复用的目的

八、迪米特法则

1.定义

i. 每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。

2.分析

i.迪米特法则就是指一个软件实体应当尽可能少的与其他实体发生相互作用。这样,当一个模块修改时,就会尽量少的影响其他的模块,扩展会相对容易,这是对软件实体之间通信的限制,它要求限制软件实体之间通信的宽度和深度。

ii. 狭义的迪米特法则:可以降低类之间的耦合,但是会在系统中增加大量的小方法并散落在系统的各个角落,它可以使一个系统的局部设计简化,因为每一个局部都不会和远距离的对象有直接的关联,但是也会造成系统的不同模块之间的通信效率降低,使得系统的不同模块之间不容易协调。

iii. 广义的迪米特法则:指对对象之间的信息流量、流向以及信息的影响的控制,主要是对信息隐藏的控制。信息的隐藏可以使各个子系统之间脱耦,从而允许它们独立地被开发、优化、使用和修改,同时可以促进软件的复用,由于每一个模块都不依赖于其他模块而存在,因此每一个模块都可以独立地在其他的地方使用。一个系统的规模越大,信息的隐藏就越重要,而信息隐藏的重要性也就越明显。

iv. 迪米特法则的主要用途在于控制信息的过载。

1.在类的划分上,应当尽量创建松耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及

2.在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限

3.在类的设计上,只要有可能,一个类型应当设计成不变类

4.在对其他类的引用上,一个对象对其他对象的引用应当降到最低。

3.实例

i.某系统界面类(如Form1、Form2等类)与数据访问类(如DAO1、DAO2等类)之间的调用关系较为复杂。如图所示:
​ ​ 在这里插入图片描述
​ ​ 在这里插入图片描述

4.图(一)和图(二)分析:

图(一)为什么到图(二)哪?因为这样就可以降低类的耦合性,是类中功能更加单一,相当于外观模式。

5.总结:

一个软件实体应当尽可能少的与其他实体发生相互作用

6.综述:

以上就是其中程序员必备的七大面向对象设计原则,原则犹如国家的法规,这就是面向对象的准则,要使我们的编程更加灵活,封装性更好,复用性更高,易于维护我们需要我们的这些原则建设我们规范我们的程序。这样我们编写的才是高质量的程序。我们每个人都这样去做,我们的编程水平一定会进步一大截!
感谢大家的支持,无论是顶的,还是踩的,都谢谢你们,希望大家互相关注,共同进步。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

许毅宏

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值