时隔多年终于更新,学习总结分享知识总是快乐的❤
0.0 译者序
作者
Matrin Fowler 软件设计大师,曾在thoughtworks(全球性软件及咨询公司)任职过
设计模式
真实问题映射为分析模型,分析模型映射为设计模型,再映射为代码,编译构建,形成系统
练习方式
- 用熟悉的语言抠一遍例子
- 模型图画成UML图,实现完整的模块图
有点意思的类比
- 分析模型分为模型的建立(type)和模型的实现(class)
1.1 概念模型
- 理解和简化问题的模型
- 针对问题设置概念模型
- 提供功能和开发维护成本之前要权衡
- 如何建模
- 通过编程语言建模
- 通过分析和设计技术(优选,因为领域专家可以充分参与)
- 概念模型面向的是接口type,而不是实现class
1.2 模式
- 四个组成部分
- 上下文的陈述
- 模式解决的问题
- 形成解决方案的影响因素
- 针对因素的解决方案
- 模式来源于真实的项目,是观察得到的
1.3 书中的模式
- 分析模式:一组概念,业务建模中的通用结构
- 支持性模式:不依赖业务领域
1.4 概念模型与业务工程再造
- 通过概念模型,实现业务工程的再造
1.5 模式和框架
- 实现组件复用,需要一个公共框架(基于特定的模型)
1.6 模型的使用
- 尝试用模型解决实际问题
- 浏览模型图,然后了解对应的模型
2.0 总结
组织层级模式(简单的组织结构)
组织结构模式(复杂饿组织结构)
责任模式:参与方模式和组织结构模式融合在一起
- 需要描述:允许形成的责任种类以及对责任的约束规则
参与方类型:
- 参与方类型泛化模式(不改变模型的情况下,将参与方划分成子类型)
- 分层责任模式(需要严格划分层级的参与方间的关系)
参与方之间的职责
- 运作范围模式(责任契约中的条款)
2.1 参与方模式
- 参与方定义为个人和组织的超类型
2.2 组织层级模式
- 使用层级关联的模式:为子类型添加约束规则来约束层级之间的关系
2.3 组织结构模式
- 层级之间的关联可以理解成一种类型(抽象的概念:不同的实例区分不同的层级关系)
- 组织结构、组织结构类型、规则
- 规则不经常变化:规则建立在组织结构类型之上,所有规则保存在一个地方
- 建模原则:建模的规律为尽量保证模型不经常变化(分析模型中的变量,将变量抽象成模块或者模型)
2.4 责任模式
- 当为超类型的类型定义特性的时候,考虑将这些特性放在超类型上是否合适
2.5 责任知识层模式
- 操作层:责任、参与方及其相互关系
- 知识层:责任类型、参与方类型及相互关系
- 知识层定义了操作层对象的合法配置,只能根据责任类型与参与方类型的对应关系创建责任
- 映射
- 知识层的多值映射:一个责任类型所允许的参与方类型的集合
- 操作层的单值映射:一个责任关系中的实际参与方
- 强力类型的两种用法(子类型有特定行为,强力类型也有自己的行为,需要同时使用映射和子类型化)
- 映射
- 子类型化
- 建模原则:应显式将模型分为操作层和知识层
- 工程中,要实现责任本身的对象模型,也应该实例化知识层。在这个过程中要考虑测试、通信等的便捷性,根据自身需要选择合适的模式
2.6 参与方类型泛化模式
- 参与方类型引入泛化机制:对责任类型的约束发生变化,可以兼顾参与方的类型(类型映射)和超类型(所有映射类型表示)
- 思考:最近开发写的updateConditions包含了各种类型以及超类型(所有映射类型的集合)
- 本质
- 参与方类型仍然是唯一的继承层级结构
- 超类型变成多值映射,从而支持多值类型
- 例子
- 如果一个医生既是全科医生,又是外科医生,需要创建一个特殊的参与方类型,全科医生和外科医生都是该特殊类型的超类型。
- 总结:参与方和参与方类型一对一,参与方类型里面可以包含多种类型
2.7 分层责任模式
- 在责任类型上建一个子类型。来包含额外的分层结构约束
- 责任类型的两个子类型
- 分层责任类型:参与方只能向唯一的具有该类型的责任负责
- 分级责任类型:参与方只能向位移的参与方类型为级别列表中的下一级的参与方负责
2.8 运作范围模式
- 描述参与方之间的相互关系(不是层级关系)
- 这里主要指运作范围(识别各种运作范围的种类及属性)
- 知识层:哪些责任类型具有哪些运作范围类型
2.9 岗位模式
- 责任与岗位有关,而不是人或者组织
- 用岗位来定义责任和运作范围
总结和思考
- 知识层和操作层应该有比较明显的区分
- 参与方可以是:人、组织、岗位
- 责任规定了参与方的职责,该职责定性可以选择多个角度:组织结构、层级关系、运作范围等
- 超类型的概念(一个type里面囊括了所有types,上方有举例)