软件体系结构与设计模式——课程总体介绍（01-03）

版权声明：就是开个版权玩一下 https://blog.csdn.net/qq_41997479/article/details/86619024

这门课是考试课+实验课，开卷考试题量大有点难，实验认真做，实验源代码见：

https://download.csdn.net/download/qq_41997479/10911963

仅供参考，以下是个人的课堂笔记，只有设计模式部分，这门课的sk老师非常负责，在学生中口碑很好，如果认真听课，课后及时总结，最后会更易读懂代码的架构以及为何这样设计的原因，对编程也有很大的帮助。

 

What is 设计模式：

每个模式有三部分原则：

1. 特定的上下文
2. 一个问题
3. 一个解决方案

定义：A solution to a problem in a context

 

Why 设计模式

设计模式好处：

1. 不那么专业的人能做出好的设计
2. 促进设计修改
3. 提升设计文档水平
4. 提升设计的可理解性

 

设计模式的问题：有舍有得，你用工具，不是工具用你

 

软件模式的分类：

1. 分析
2. 设计
3. 分类
4. ……

 

设计模式分类：（记住）

1. 创建型
   1. 抽象工厂（CH 7 介绍）
   2. 建造者
   3. 工厂方法（CH 6 介绍）
   4. 单例模式（CH 9 介绍）
2. 结构型
   1. 适配器（CH 11介绍）
   2. 桥接
   3. 组合（CH15介绍）
   4. 装饰器（CH 8 介绍）
   5. 门面（CH 12介绍）——实际上属于架构模式
   6. 享元(CH 18介绍)
   7. 代理
3. 行为型
   1. 责任链
   2. 命令（CH 10介绍）
   3. 解释器
   4. 迭代器（CH 14介绍）
   5. 中介者
   6. 备忘录
   7. 观察者（CH4 介绍）
   8. 状态（CH 16介绍）
   9. 策略(CH5介绍)
   10. 模板方法（CH 13介绍）
   11. 访问者

 

提纲：

• UML notation
  • 类图：静态数据结构，展示类的属性和方法

• 面向对象设计原则（必须理解）
  • 七宗罪
    • 僵化：很难改
    • 脆弱：easy to break
    • 固化：hard to reuse
    • 粘滞:hard to do the right thing
    • 非必要复杂性:over design
    • 非必要重复:
  • 7种原则

• SRP单一职责原则
  • 一个类允许只有一个改变的原因，最好只有一个功能
  • 增加内聚性，一个模块组成元素之间的功能相关性
  • 一个类若有多个职责，增加耦合性
  • 做机器人，不能做头类，因为眼睛、鼻子等大小可变
  • 不足：增加负担，本来一个类封装好了，再拆开增加工作量
• OCP开放封闭原则
  • 对扩展开放，对修改关闭
  • 不破坏原有功能
  • 已经经过了测试的代码段就不用改了
  • 在不重新设计的前提下系统支持什么样的变化
  • 实现：抽象，多态，继承
• LSP里氏替换原则
  • S是T的一个子类，凡是T出现的地方都能用S替换
  • 任何基类出现的地方，子类也可以出现
  • 子类的实例 IS A 超类的实例
  • 实现：契约式设计——前置条件和后置条件
  • 正方形和矩形is a 四边形，而不能是正方形（边长：a）是矩形(长：a,宽:b)
  • 要聚合不要继承，has a 比is a要好
  • 子类可扩展父类的功能，但不能改变父类的功能
     
• ISP接口分离原则
  • 要最小的接口
  • 单一职责的接口版本，即实现出来的内聚性就高
  • 为了避免client之间不必要的耦合性
• DIP依赖倒置原则（好莱坞原则）
  • 依赖：A类方法中使用了B类，则A类依赖于B类
  • 高层模块不应该依赖于低层模决，二者都应该

依赖于抽象。进一步的，抽象不应该依赖于细

节，细节应该依赖于抽象。

• 例子：猎人拿枪类和斧子类，变为玩家类拿武器类
• 优点：降低僵化，灵活，增加松耦合
• 实现：高层实现所需服务的接口，低层实现这些接口
  • 上层通过这些接口使用下层的服务，因此上层不依赖于下层
• 规则：
  • 参数中的类不应该是具体类，应该是一个接口或者抽象类
  • 抽象类往上去，具体data和具体类往下去
  • 
• 核心：
  • DIP 主要用于解耦
  • 针对接口编程，不针对实现编程
  • 在继承的层次结构层次中:
    • 共享代码应该移动到抽象级别(更高层次结构级别)的抽象类
    • 私有数据应该移动到实现级别(更低层次结构级别)的具体类
• 如果需求稳定，抽象类意义不大
• 接口应该由服务请求者确定，而不是服务提供者

• SOLID代表以上5个设计原则使软件可理解、可维护、可扩展（flexible）
  • CRP组合/聚合复用原则
    • 多用组合/聚合，少用继承
    • 聚合/组合代表has a
    • 
    • 继承复用是白盒复用，强耦合，子类知道父类的具体实现
    • 聚合复用是黑盒复用，低依赖，被包含对象的细节对于客户机是不可见的
    • 
  • PLK最小知识原则(也叫Law of Demeter，LoD)
    • 每个单元只跟有限的对象有耦合
    • 我的朋友很少，但是少而精
    • 不要让太多的类耦合在一起，否则系统某一部分的修改会影响到其他部分
    • 易于维护理解

• 23种经典设计模式
• 总结