
模式:在一定环境中解决一些问题的方案(通俗点讲就是:特定环境用固定的套路解决问题)
设计模式设计模式是一套反复被人使用,多数人知晓的,经过分类编目的代码设计经验的总结
设计模式就是固定的、写代码的一种思维逻辑方式,设计类与类之间关系的时候,抽象思维的一种定式
设计模式最终的目的为了应对变化,提高代码的复用和重用性,减少代码的修改去应对变化
-
客户需求的变化
-
技术平台变化
-
开发团队的变化
-
市场环境的变化
... ...
-
创建型模式
通常和对象创建有关,设计到对象实例化的方式(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
-
子类必须能够替换它们的基类(尽量减少派生的形式)
-
继承表达类型抽象(在多态的时候,子类可以替换父类指针的使用)
-
通常会抽象一个抽象层出来,用抽象层去描述一些行为,描述一些方法,只需要传入一个子类对象去充当参数就可以完成相应的 *** 作
-
在设计类的一些成员函数的时候需要注意的一些特点
-
不应该强迫客户程序依赖他们不用的方法
-
接口应该小而完备
-
内部接口尽量私有化
-
一个接口应该只提供一种对外功能(与函数设计的原则是一样的,一个函数一个功能)
CARP:Composite/Aggregate Reuse Principle
-
类的继承通常是"白箱复用:父类中的东西子类可以看到",对象的组合通常是"黑箱复用:对于组合类来说,仍然受类外的权限限定,只能通过对象去调用组合类里面的东西,而不能直接使用"
-
继承在一定程序破坏封装性,子类和父类耦合度高(关联度高)
qt 中大部分控件都是继承于同一个类的,再互相继承没有太多含义,自己写一个窗口继承原窗口的父类其实没有什么作用,而且显得特别累赘
父类中的属性一旦被继承,产生的子类越多,子类的属性会越庞大
所有的原则都是追求低耦合(关联越少越好),高内聚(自身只与自身有关系)
迪米特法则(LOD)LOD:Law of Demeter
-
对象应当对其他对象尽可能少的了解
-
各个模块之间相互调用时,通常会提供一个统一的接口来实现
女朋友想和你基友有什么要说的,通过你去转达给你基友,这就是不和陌生人说话的一种设计方式,不允许有直接的交流,尽量减少类与类之间的沟通、交流
可以组合使用,可以通过迪米特法则结合依赖倒转原则抽象一个中间层出来去解耦合,可以理解为你女朋友和她的闺蜜之间进行沟通(因为第一种设计感觉有点别扭,交流反而更多了)
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)