设计模式-前导知识

1.软件生命周期（详细：软件工程）

1.1 软件生命周期

1.2 软件过程模型：

瀑布模型、原型模型、迭代模型、螺旋模型、统一过程模型、敏捷模型
软件过程：由软件生命周期中各个阶段的活动构成
软件过程模型定义了软件过程中各个阶段的工作任务，并没有指出如何实现这些活动。

1）瀑布模型

每个阶段依赖上一阶段，并且反馈消息给上一阶段

• 计划阶段 P
  可行性分析
  成本分析
  输出：计划书
• 需求分析 R
  输出：软件需求分析说明书
• 软件设计 D
  功能设计
  性能设计
  用户接口设计
• 编码 C
  码农用武之地
• 测试 T
  集成测试
  单元测试
• 维护/运行 M

1.3 软件开发方法：

结构化方法、面向对象方法、敏捷统一方法
软件开发方法定义

1）结构化方法

模块为核心，自顶向下或者自底向上

2）面向对象方法

3）敏捷统一方法

结合上述两种方法

2. UML

13种图，常用的有10种
用例图-用例模型
时序图、活动图、协作图-交互模型
状态图-状态模型
类图、对象图-逻辑模型
组件图、包图-组件模型
部署图-部署模型

2.1 用例图 Use Case Diagram

• 用例（椭圆形，动宾短语命名）（系统提供的服务或者功能）
• 参与者（人形符号，名词短语命名）（用户、与软件有交互的其他第三方系统）
• 关联（直线）
• 系统边界（矩形框）
  eg.
  订餐系统COS
  参与者Actor：客户Patron、管理者Admin、配餐员Deliver
  用例Use Case：生成订单，登录系统，注册账号…

2.2 时序图 Sequence Diagram

图形元素：

• 对象 （矩形框，冒号分隔，冒号前面是对象名称，冒号后面是对象类型，下划线表示对象的标志）
• 生命线 （虚线）
• 活动条 （当对象被激活，矩形条表示）
• 消息 （不同对象之间的活动，箭头表示，箭头上方写消息名字，后接方括号内为数据，多个数据逗号分隔）
• 控制流
  顺序控制流
  分支 （矩形框，虚线分隔，上方分支条件为真时执行，左上方
  循环（矩形框，左上角loop，方括号内循环条件）

2.3 类图 Class Diagram

类图元素：

• 类名（命名规则余弦样式，名词或名词短语，首字母大写；）
• 属性（命名规则正弦样式，名词或名词短语，首字母小写）
• 方法（命名规则正弦样式，动宾短语，首字母小写）
• 可见性（+ public，- private，# protected）
• 数据类型（变量名称：变量类型）

类之间关系

• 关联关系 （实线，无箭头）(–Assosiation)
• 依赖关系（虚线，带箭头）(…>Dependency)
• 继承关系（实线，三角箭头，箭头指向父类）（–|>Inheriatance）
• 实现关系（虚线，三角箭头）(…|>Realization)
• 组合关系（也叫强聚合关系）（实线，实心菱形箭头）(–*Composition)
• 聚合关系（实线，空心菱形箭头，箭头指向聚合体，箭尾指向被聚合对象）(–o Aggregation)
• ()(–> Assosiation)
• ()(… Link)

3. GoF设计模式（经典四人帮设计模式）

面向对象设计原则
教材：GoF.Design Patterns:Elements of Reusable ObjectOriented Software.2002

3.1 用例建模

建模过程：
识别抽象用例–>标注高级用例–>分析扩展用例–>用例模型可视化

3.1.1 识别抽象用例

是否是一个业务过程
参与者是谁
是否由参与者出发

3.1.2 标注高级用例

TUCBW：
TUCEW

3.1.3 分析扩展用例

前置条件
后置条件
|—|---|
|–

3.1.4 用例模型可视化

3.2 领域建模

3.2.1 采集领域信息

3.2.2 头脑风暴

3.2.3 领域知识分类

3.2.4 模型可视化

3.3 对象交互建模

3.3.1 识别非琐碎步（Nontrivial Step）

3.3.2 情景分析建模

3.3.3 构建情景表

#	主语对象	主语发送对象的动作

3.3.4 模型可视化

3.4 设计类图

3.4.1 设计过程：

1. 从领域模型中抽取设计类
2. 从对象交互模型中抽取设计类
3. 设计/抽取类的属性
4. 设计/抽取类方法
5. 设计/抽取类关系

3.4.2 设计原则：

SOLID原则

1. 单一职责原则 SRP（Single Responsibility Principle）

优点
- 代码稳定
- 代码简单易于维护

2. 开放闭合原则 OCP (Open-Close Principle)

Open to extension
Close to modification

3. 依赖反转原则 DIP (Dependency Inversion Principle)

-  高级模块不应该依赖低级模块，两者应该依赖抽象模块
-  对象对象不应该依赖具体对象，而是具体对象应该依赖抽象对象

高低级模块区分
指代码中承担实现的模块为低级模块，调用模块为高级模块。比如A对象中调用B的某方法，则B为低级模块，A为高级模块。

4. 接口隔离原则 ISP（Interface Segregation Principle）

客户类不应该被强制实现、依赖它们不需要的接口/功能。
解决方法：1.将超类的抽象方法或者接口分解，只包含单一功能。

5. 里氏替换原则 LSP（Liskov’s Substitution Principle）

子类可以完全代替父类；
子类继承父类时不应该改变父类的行为、功能。
通俗的说：子类要么不要重写父类的方法，要重写则必须保证功能完全一致，负责会导致歧义。

6.DRY原则

7.KISS原则

8.YANGI原则

9.LOD法则

4. 通用责任链分配（Grasp）设计模式

教材:David C.Kung. Object-Oriented Software Engineering:An Agile Unified Methodology.2013
软件设计和代码编写准则，分为控制器模式、创建者模式、信息专家模式。

4.1 专家模式 Information Expert Pattern

信息专家对象：拥有业务请求所需信息数据的对象。
专家模式：请求的处理行为应该赋予信息专家对象
信息专家可能会承担过多职责

eg:
	登录请求的密码验证，应该在User类中实现，并不是在Controller类中。否则会破坏User类的封装性。

4.2 控制器模式 Controller Pattern

1. 接收业务请求，并将请求分发至业务处理对象；
2. 接收业务请求处理结果，并将结果分发至响应页面。
   控制器对象可能会承担过多逻辑职责

Spring MVC中的C即是Controller，M Model，V Viewer
Controller 负责逻辑分发，例如
登录业务中：
登录请求的接收者： 从Viewer产生请求，Controller接收
处理请求业务实现： Controller，分发至Model处理
接收响应：Model

4.3 创建者模式

如下情况中，A类对象应该是B类对象的创建者：

1. A类对象是B类对象的聚合体
2. A类对象包含B类对象
3. A类对象使用B类对象
4. A类对象记录B类对象的状态
5. A类对象拥有创建B类对象的数据/信息
   *同一个对象可能有不同的创建方式

User类对象应该由谁创建？
Controller使用User，有Controller创建
Controller包括登录、创建、修改控制层，会导致创建方法不一样。

编程规范

20条快速改善代码质量的编程规范

代码重构

1.目的、对象、时机、方法

2.单元测试和代码的可测试性

3.大重构（大规模高层次）

4.小重构（小规模低层次）

参考

- [1]  王争.23种设计模式的原理、背后的思想、应用场景[N].InfoQ 微博文章，2021-1-26
- [2] Erich Gamma,Richard Helm,Ralph Johnson,John Vlissides.设计模式[M].北京:机械工业出版社,2019.3（2020.6重印）
- [3] 朱洪军.软件设计模式[Vidoe].学堂在线(2020秋).2020

仅用作学习非商用，侵权联系本人，立即删除。

Markdown画类图语法要点

注释

%%

定义类的两种方法

方法一