对象设计
2021-09-01 20:41:21 0 举报AI智能生成
对象设计角色、责任和协作
作者其他创作
大纲/内容
对象.png
软件的部分——对象
部分到整体
需要对完整的真实世界进行建模？
误区
用对象模拟现实世界中的信息、过程、互动、关系甚至错误
是否满足应用需求
衡量
如何制造软件机器？
1.1 对象机器
一组可以相互替换使用的责任
定义
对象不会独立存在，它是机器的一部分
为了生存，对象将具有特定的使命——在给定环境中扮演一种角色
隐喻
1.2 角色
描述对象的责任
掌握并提供信息
信息持有者：
维护对象之间的关系以及与这些关系相关的信息
构造者：
执行工作，通常为其他对象提供服务
服务提供者：
通过向其他对象委托任务来响应事件
协调者：
进行决策并指导其他对象的行为
控制者：
连接系统的各个部分，并在它们之间进行信息和请求的转换
接口：
eg.
1.3 角色模式（role stereotypes）
软件实现了一个责任系统。不同的角色通过协作履行不同的责任
对象通过相互调用或协作，一起共同履行更大的责任
对象通过责任来体现角色
对象协作.png
1.4 角色、责任和协作
在何种条件下可以保证工作的正常进行
以及它将对系统中其他成员产生什么影响
对象与系统中的哪些实体互动
使用条件
使用效果
核心
1.5 对象契约
领域对象为开发者与用户一起讨论系统提供一个公共背景。它代表的是用户和特定领域专家所熟悉的概念。
账户、存款、提取额、利率等
银行系统
预定、航班、座位、目的地、时刻表等
航空票务预订系统
领域对象.png
1.6 领域对象
接口、协调者、特定的服务提供者，弥补领域对象的不足，将系统粘合起来
领域内的信息、服务以及规则等
关心更抽象、更逻辑的观点
用户和领域专家
外部系统及设备连接、处理之间的协调关系、连接关系等
关注系统
开发者
关注点
app 特定对象.png
1.7 app 特定对象
接口公布服务，并说明如何请求
公开的接口
实现的细节
对象设计3部分
1.8 接口
类用来描述相同事物的集合
数学意义
可以被卡片来描述、可以被设计符号化，还可以被编码实现
简单抽象
类实体的“知”、“行”or“决策”
类定义
软件类
负责初始化程序运行所必须的实体
对象工厂.png
工厂
为与其有关联的客户提供服务
一个服务提供者.png
一个独立的服务提供者
两类角色
1.9 类
复合关系是动态的，发生在参与其中的对象生命期，并且可以改变
一个对象通过协作来调用另外一个对象的责任
1.10 复合
继承是静态的，父类的责任和子类对其的扩展都是在编译期完成
一个对象通过继承拥有另外一个对象的责任
一个类所处的继承体系位置越高，实际能完成的职责就越少
Peter 原则
1.11 继承
对象关系
对象联盟由大量的潜在对象构成，并具有一些复杂的集体行为。
联盟成员之间倾力合作形成一个新的高层次的概念实体
对象联盟.png
子系统 or 对象领域
1.12 对象的组织
还有另一种组织设计，组件可以用于不同应用的设计元素。
组件的内容是隐藏的，它通过定义精确的接口对外提供服务
1.13 组件
将Double Dispatch 模式应用于特定问题
运用模式的现实利益
1.14 模式
应用框架就是用于解决软件问题的通用设计
模式是解决特定问题的方案，是一种思想
框架提供了一个类库，开发人员可以裁剪或扩展它以适应特定的环境
PK 模式
Java Swing 框架提供建立互动性用户接口的一系列功能
GUI
Eclipse 集成开发环境的插件体系让工具开发人员可以在它之上开发不同的编译器、重构工具以及调试器
编程环境
框架.png
1.15 应用框架
框图描述的只是结构，完全忽略了行为
框图是体系结构？
一个体系结构包含了一系列行为，以及对行为之间相互影响的描述
概念视图、控制流程视图、组件和子系统视图、对象和互操作视图等
不同抽象层次的视图
1.16 体系结构
组件交互风格
控制风格
体系风格
以板块结构图来描述组件的交互，这些图所表示的是系统的组件层级，并描述它们之间的互动关系
层级体系.png
层次式（layered）
管道-过滤器式（pipes-and-filters）
黑板式（blackboard）
常见体系风格
总概
过程化编程
将大量的算法集中于一个“聪明对象”中，而在它周围环绕一群POJO
适用简单业务场景
逻辑集中于少量的“聪明对象”中
优点
集中式控制.png
集中式控制
分散式.png
分散式控制
两个极端控制风格的中间
每个对象封装了履行其责任所需要的信息，不过偶尔，它们也需要请求其他对象的帮助
委托式控制.png
委托式控制
测试互动：一个层次体系的例子
定位层次中的对象
1.17 体系结构的风格
CRC 卡
1.18 设计描述
1.20 更进一步阅读
1.设计的概念
启动生产过程：项目的定义和计划
搭建舞台：初期的描述
实施开发：设计
从多视角“观察”
2.1 观察、描述和设计的过程
用法描述
其他规范
术语表
概念上的对象
2.2 撰写草稿：分析描述
创造：运用模式
寻求解决方案
在思想与细节之间跳跃
2.3 铸造特性：挖掘设计
弹性和可扩展设计
可靠性设计
使设计具有可预见性、一致性并易于理解
2.4 调整产品：精练设计
2.责任驱动设计
3.1 发现策略
3.2 寻找对象、角色和类
3.3 why need 设计纲领
3.4 寻找的策略
3.5 名字到底有何内涵
3.6 描述候选对象
3.7 特征化候选对象
3.8 连接候选对象
3.9 寻找共同背景
3.10 审核已有对象，寻找其他对象
3.发现对象
4.1 what 责任
4.2 where 责任
记录责任
进行初始分配
解除困扰
4.3 责任分配策略
4.4 实现对象和责任
4.5 检测对象的质量
4.责任
为协作做准备
记录候选协作
5.1 what 对象协作
5.2 Speak for Me 软件的设计故事
5.3 协作的选择
审视个体对象的角色：构造型隐含协作
审视个体责任：他们隐含着协作
为复杂责任设计细节
为特定的任务设计协作
确认可用的模式
确认体系结构怎样影响协作
解决协作中的问题
5.4 确定协作的策略
计划编制一个模拟
执行一个模拟
5.5 模拟协作
5.6 设计优良的协作
5.7 让协作成为可能
5.8 何时结束
5.协作
6.1 what 控制风格
6.2 可选的控制风格
委派书控制
控制决策的局限性
6.3 衡量各方案利弊
6.4 设计控制中心
MessageBuilder 对象的集中式控制
将决策重构入MessageBuilder对象的状态方法中
抽取决策权
委派更多责任
为相邻对象设计控制风格
设计类似的控制中心：具有一致性
6.5 eg.外部用户事件的控制风格
6.控制风格
7.1 协作的提纲
7.2 协作的策略
7.3 确立作用范围、深度和基调
7.4 列出所要包含的内容
显示一个鸟瞰视图
只显示协作者
显示协作者之间的互动顺序
显示深度视图
显示焦点互动
显示现实视图
显示如何改编协作
UML 的不足之处
7.5 决定细节层次
7.6 选择适当的形式
7.7 讲述、绘制以及描述：指导方针
加强重视
展开提纲
了解基础内容
进行总结
7.8 组织你的工作
7.9 保留提纲
7.描述协作
8.1 理解失败的后果
8.2 增加系统的可靠性
可信任 PK 不可信任
信任的内涵
8.3 确定协作在何处可被信任
8.4 确认哪些协作需要可靠性
8.5 设计一种解决方案
8.6 建立异常处理设计文档
8.7 回顾你的设计
8.可靠的协作
9.1 弹性意味着什么
9.2 弹性的程度
9.3 弹性解决方案的效果
9.4 明确弹性需求
9.5 记录变化
明确一个变化的影响力
探讨实现弹性的策略
使用模板和Hook 机制来支持变化
9.6 变化及其实现
以策略模式改变对象的行为
使用中介者隐藏交互对象
使用适配器安装一个预定义对象或系统
模式是如何增加弹性的
9.7 模式在弹性设计中的角色
9.8 怎样建立弹性设计的文档
9.9 修改遗留系统的设计
9.弹性
10.1 软件设计的本质
10.2 解决核心设计问题
10.3 确定问题框架（Frame the Problem）
一个管理共享信息的例子
一个连接问题的复杂性例子
难度永远不会降低的设计问题
启示性问题是否可以“另类”
10.4 处理启示性设计问题
重新定义问题
合成一个解决方案
10.5 解决启示性问题的策略
10.6 处理剩余问题
10.7 设计职责
10.关于设计
对象设计
0 条评论
回复 删除
下一页
