c++ 设计模式介绍与基本原则

设计模式初识

什么是设计模式

模式

模式:在一定环境中解决一些问题的方案(通俗点讲就是:特定环境用固定的套路解决问题)

设计模式

设计模式是一套反复被人使用,多数人知晓的,经过分类编目的代码设计经验的总结

设计模式就是固定的、写代码的一种思维逻辑方式,设计类与类之间关系的时候,抽象思维的一种定式

设计模式最终的目的为了应对变化,提高代码的复用和重用性,减少代码的修改去应对变化

  1. 客户需求的变化

  2. 技术平台变化

  3. 开发团队的变化

  4. 市场环境的变化

    ... ...

设计模式分类

  • 创建型模式

    通常和对象创建有关,设计到对象实例化的方式(5种)

    • 工厂模式

    • 抽象工厂模式

    • 建造者模式

    • 原型模式

    • 单例模式

  • 结构型模式

    描述的是如何组合类和对象获得更大的结构(7种)

    • 代理模式

    • 装饰者模式

    • 适配器模式

    • 桥接模式

    • 组合模式

    • 外观模式

    • 享元模式

  • 行为型模式

    描述的是类和对象的交互( 成员函数的设计 )以及分配职责(11种 )

    • 模板方法模式

    • 命令模式

    • 责任链模式

    • 策略模式

    • 中介者模式

    • 观察者模式

    • 备忘录模式

    • 访问者模式

    • 状态模式

    • 解释器模式

    • 迭代器模式

// 23

了解、理解设计模式的七大原则

面向对象的设计原则

依赖倒置原则(DIP)

DIP:Dependence Inversion Principle

  • 高层(稳定)不依赖低层(变化),两者依赖抽象(稳定)。

  • 抽象(稳定)不依赖细节(变化),细节依赖抽象(稳定)。

下图是一个水果店,水果店会产生一些水果

水果店是高层,香蕉、橘子、苹果等是低层,水果店依赖于这些水果,所以叫做水果店,如果水果店想卖一些其他东西相对来说比较麻烦

高层依赖于低层,违背了高层不依赖低层,可以抽象出一个(中间层) 水果层,水果店(第一层)依赖于抽象层,如果有新的水果,也可以直接把它放到水果篮子里面就可以了

如果还有饮料就可以再抽象一个中间层出来,也可以算是水果店的

在做拓展的时候,相对来说是极其方便的

高层不依赖于低层,依赖于抽象层,抽象层不依赖于细节,细节依赖于抽象层,所以通常会构造一个抽象层出来

开放封闭原则(OCP)

OCP:Open For Extension,Closed For Modification Principle

  • 对扩展开放,对更改封闭

  • 类模块可扩展, 但不可修改

轻松模式中,如果客户想做存款业务就只做存款业务,如果想做取款业务就只做取款业务. . .每个客户只做一件事情,效率增加

把所有的职责开放出来而不是放到同一个银行员工 / 类当中

单一职责原则(SRP)

SRP:Single Responsibility Principle

  • 一个类应该仅有一个引起它变化的原因

  • 变化的方向隐含类的责任

与做模块化设计是一样的,一个函数只有一个功能,在设计类的时候,一个类尽量只有一个职则

里氏替换原则(LSP)

LSP:Liskov Substitution Principle

  • 子类必须能够替换它们的基类(尽量减少派生的形式) 

  • 继承表达类型抽象(在多态的时候,子类可以替换父类指针的使用)

  • 通常会抽象一个抽象层出来,用抽象层去描述一些行为,描述一些方法,只需要传入一个子类对象去充当参数就可以完成相应的操作

接口隔离原则(ISP)

  • 在设计类的一些成员函数的时候需要注意的一些特点

  • 不应该强迫客户程序依赖他们不用的方法

  • 接口应该小而完备

  • 内部接口尽量私有化

  • 一个接口应该只提供一种对外功能(与函数设计的原则是一样的,一个函数一个功能)

优先组合不是继承原则(CARP)

CARP:Composite/Aggregate Reuse Principle

  • 类的继承通常是"白箱复用:父类中的东西子类可以看到",对象的组合通常是"黑箱复用:对于组合类来说,仍然受类外的权限限定,只能通过对象去调用组合类里面的东西,而不能直接使用"

  • 继承在一定程序破坏封装性,子类和父类耦合度高(关联度高)

qt 中大部分控件都是继承于同一个类的,再互相继承没有太多含义,自己写一个窗口继承原窗口的父类其实没有什么作用,而且显得特别累赘

父类中的属性一旦被继承,产生的子类越多,子类的属性会越庞大

所有的原则都是追求低耦合(关联越少越好),高内聚(自身只与自身有关系)

迪米特法则(LOD)

LOD:Law of Demeter

  • 对象应当对其他对象尽可能少的了解

  • 各个模块之间相互调用时,通常会提供一个统一的接口来实现

女朋友想和你基友有什么要说的,通过你去转达给你基友,这就是不和陌生人说话的一种设计方式,不允许有直接的交流,尽量减少类与类之间的沟通、交流

可以组合使用,可以通过迪米特法则结合依赖倒转原则抽象一个中间层出来去解耦合,可以理解为你女朋友和她的闺蜜之间进行沟通(因为第一种设计感觉有点别扭,交流反而更多了)

  • 4
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

qiuqiuyaq

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

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

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

打赏作者

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

抵扣说明:

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

余额充值