设计原则与设计模式
目录
八大设计原则
看了李建忠老师的C++设计模式视频后的一些总结。
依赖倒置原则
- 高层模块不依赖底层模块，二者都应该依赖抽象，
- 抽象不依赖实现细节，实现细节应该依赖于抽象。
这一原则与下面的针对接口变成而不是针对实现编程是一个道理，我们设计一个程序，我们应该先想好我们想要抽象什么，它应该具有什么样的能力，而不是先考虑怎么实现，这其中的具体方法，而最后在根据自己写的具体实现，从而汇总出最后的接口是什么。
开放封闭原则
- 对拓展开放，对更改封闭
- 类模块应该是可 拓展的，但是不可修改的。
我们应该定义好接口之后就尽可能保证接口层的稳定，
单一职责原则
- 一个类应该仅有一个引起他变化的原因
- 变化的方向隐含类的责任
若一个类中变化的部分过多，从而加剧了程序的维护难度，从而也许会修改这个类中的接口部分，也就违反了上面的第二原则。
其中变化（使用的具体实现等等），其中一定要明确这个部分中的具体目的。
里氏替换原则
- 子类必须能够替换他们的基类。
- 继承表达类型的抽象。
假如子类不可以替换他们的基类那么大部分的设计模式都无从谈起。
接口隔离原则
- 不应该“强迫”客户程序依赖他们不用的方法。
- 接口应该小而完备。
设计对象的时候我们应该明确的知道这个对象应该要包含什么功能，然后做出相应的接口，其余一些客户不用的方法全部隐藏起来。
优先使用对象组合，而不是类继承
- 白箱复用：将父类的全部内容暴露给子类。
- 黑箱复用：只暴露想暴露的部分，其余的内容对其类不可见。
- 类继承通常称为白箱复用
- 对象组合通常被称为黑箱复用
- 继承在某种程度上破坏了封装性,子类父类耦合度高
- 对象组合则只要求被组合的对象具有良好的定义的接口。
封装变化点
- 使用封装来创建对象之间的分界层，
- 让设计者可以在变化的另一侧修改，而不会对另一侧产生不良影响，从而达到层次间的松耦合。
针对接口编程，而不是针对实现编程
- 不将变量类型声明为某个特定类型的具体类，而是声明为某个接口。
- 客户程序无需知道对象的具体类型，只需要知道对象所具有的接口。
- 减少系统中各部分的依赖关系，从而实现”高内聚，松耦合“的类型设计方案。
23种设计模式
设计模式手段
- 管理变化，提高复用
设计模式是依托于设计原则的具体方法论，核心还是在于分离变化与稳定部分，提高代码复用率。
- 分解与抽象
使用设计模式时首先对结构、场景、需求进行分析、分解为一个抽象的概念，务必准确，否则难以使用正确的模式和出现偏差。
重构方法
设计模式依托于重构，并非一开始就能使用到准确的模式，设计模式常常采用的原理都有如下的方法：
- 静态-->动态
- 早绑定-->晚绑定
- 继承-->组合
- 编译时依赖-->运行时依赖
- 紧耦合-->松耦合
模式分类
- 组件协作：
- 模板方法
- 策略模式
- 观察则/订阅模式
- 单一职责：
- 装饰器模式
- 桥接模式
- 对象创建：
- 工厂方法
- 抽象工厂
- 原型模式
- 建造者模式
- 对象性能：
- 单例模式
- 享元模式
- 接口隔离：
- 门面模式
- 代理模式
- 适配器模式
- 中介者模式
- 状态变化：
- 备忘录模式
- 状态模式
- 数据接口：
- 组合模式
- 迭代器模式
- 职责链模式
- 行为变化：
- 命令模式
- 访问者模式
- 领域问题：
- 解析器模式
什么时候不用设计模式
- 代码可读性很差时
代码可读性很差，难以理清软件的结构，此时不是应该想到使用设计模式去改变代码，而是首先进行重构代码，设计模式是在软件本身清晰的前提下进行的。
- 需求理解很浅时
对于软件本身的需求不明确，此时应该考虑明确需求，否则做再好的设计也难以应对随时变化的需求。
- 变化没有明显时
设计模式本身是针对存在变化与稳定两部分的代码结构时才会使用的手段，代码一尘不变或全都是变化点时使用任何涉及模式都没有意义。
不是系统关键依赖
项目没有复用价值时
不会再被使用的项目，我们称它是不变的，再好的涉及也得不到效益回报。
- 项目即将要发布时
涉及模式是需要重构的，因此无法避免会引入缺陷。
经验
- 不要为模式而模式
- 关注抽象类和接口（是设计，是架构）
- 理清变化点和稳定点（重要事情说三遍）
- 审视依赖关系
- 要有
framework（架构）和application（应用）的区隔思维（分清角色）- 良好的涉及是演化的结果（不是异步到位的，重构、迭代）
阶段
- 见模式而不知
- 可识别模式，作为应用开发人员使用模式
- 作为框架开发人员为应用设计某些模式
- 没有特定设计模式，只有设计原则，设计模式本身只有那么多种，而设计原则变化无穷。
浙公网安备 33010602011771号