前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >2.设计模式-七大原则(C++)

2.设计模式-七大原则(C++)

作者头像
诺谦
发布2021-07-08 15:03:03
5280
发布2021-07-08 15:03:03
举报
文章被收录于专栏:Linux驱动Linux驱动Linux驱动

任何一个设计模式都离不开七大原则中的任一原则.所以七大原则非常重要,只要我们明白了七大原则,就可以知道如何在项目中使用什么设计原则了.

设计模式的七大原则如下所示:

  • 1.单一职责原则
  • 2.开放-封闭原则
  • 3.依赖倒置原则
  • 4.里氏替换原则(LSP)
  • 5.接口隔离原则
  • 6.迪米特原则(最少知道原则)
  • 7.合成复用原则

1.单一职责原则

  • 一个类应该仅有一个引起它变化的原因。
  • 变化的方向隐含着类的责任。

每个类都做独立的事情,如果类的功能太多,可能引起它变化的原因就越多,这将导致功能依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合度。

比如视频的解封装和解码,如果放在一个类,那么以后想改变策略,本地不解码,只是转发解封装后的数据到另个地方,那么将会导致冗余,以前写的代码到底该不该删除?所以最好分开实现!

2.依赖倒置原则

  • 高层模块(稳定)不应该依赖于低层模块(变化),二者都应该依赖于抽象(稳定)
  • 抽象(稳定)不应该依赖于实现细节(变化) ,实现细节应该依赖于抽象(稳定)

比如我们之前用多态实现的画板程序:

  • 对应的高层模块就是 : PainterWindow(稳定的类、应该只操作Shape抽象类)
  • 底层模块是 : Line、Rectangle(具体的类、容易变化的)
  • 抽象模块是 : Shape(抽象类、提供稳定的接口)

其实我们这里的mouseUp()里实现的不是很好,因为有操作具体的底层模块.

我们应该提供一个工厂类给mouseUp()使用,通过工厂类来创建用户要画的什么图形.从而让我们的高层模块(PainterWindow)实现稳定效果,以后增改需求,就不需要改这个类了。

3.开放-封闭原则

  • 对扩展开放,对更改封闭。
  • 类模块应该是可扩展的,但是不可修改。

比如我们之前用多态实现的画板程序,当我们添加一个椭圆类时,只需要新增椭圆类文件,然后在工厂类中添加一个生成椭圆类的代码即可(扩展是开放的,并且无需更改原有的代码).

4.里氏替换原则(LSP)

  • 子类必须能够替换它们的基类(IS-A)。
  • 继承表达类型抽象。

父类出现的方法,子类应该也要出现,通过调用父类的方法来实现虚函数调用子类.从而实现替换(不同子类实现的效果不同,但是调用父类的代码是相同的).

5.接口隔离原则

  • 不应该强迫客户程序依赖它们不用的方法。
  • 接口应该小而完备。

使用多个专门的接口,而不使用单一的总接口,即类不应该依赖那些它不需要的接口。比如后期该接口发生了变化,那么这个类也要去进行修改,增大修改的成本

6.迪米特原则(最少知道原则)

  • 不将变量类型声明为某个特定的具体类(比如Shape的Line子类),而是声明为某个接口(Shape类)
  • 客户程序(PainterWindow类)无需获知对象的具体类型(Line、Rectangle),只需要知道对象所具有的接口(Shape)
  • 减少系统中各部分的依赖关系,从而实现“高内聚、松耦合”的类型设计方案

7.合成复用原则

  • 优先使用对象组合,而不是类继承
  • 继承复用:又称"白箱复用",容易破坏封装性,耦合度高,不利于类的扩展和维护
  • 组合或聚合复用:又称"黑箱复用",耦合度低,灵活度高
  • 对象组合只要求被组合的对象具有良好定义的接口,耦合度低。

继承的原则是用来子类替换基类,如果一味地使用类继承,那么之类的子类会继承出很多不需要的属性,在后面的设计模式中会举例出来.

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2021-07-03 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档