没有完美的类结构,也没有一组正确的对象。设计选择是许多竞争因素的折中。OOA提出了一些有用的、值得推荐的实践和经验法则。
确定类之间的泛化、特化、聚合等层次结构;识别对象交互的共同模式,发明机制;指导模块化。
发现一种秩序不容易,但一旦秩序被发现,了解并没什么难度。需要很多艰苦的工作才能设计出简单的架构。
分类难,最好通过一个增量式、迭代式的过程来完成
初建,基于经验修改:新建子类、分解类、组织类、设计新类等
为何难:不存在完美分类(视角不同则划分不同);明智分类要创造性思维(品味问题)
1) 经典分类
利用相关的属性作为对象间相似性的判据。(根据某一属性是否存在)
考虑哪些属性,与领域高度相关。
2) 概念聚集
类(一些实体的聚集)的产生首先是形成类的概念描述,然后再根据这些描述对实体 进行分类
3) 原型理论
对象的类是由一个原型对象来代表,如果其他对象与它表现出重要的相似性,就被认为是这个类中的一员。
4) 应用经典理论和现代理论
以上三种都可应用于OOA。 根据领域相关属性来确定类和对象。
关注问题空间词汇表的结构和行为。接下来,按概念来聚集对象(或按概念来优化最初的基于领域的分类)
关注协作对象的行为。接下来,考虑按关联度分类。
1) 经典方法
类和对象:实物、角色、事件、交互
数据库:人、地点、物、组织、概念、事件
对象:结构、其他系统、设备、要记住的事件、扮演的角色、位置、组织机构单位
2) 行为分析
经典方法关注实实在在的事物,另一思路是关注动态的行为。
更像概念聚集,根据一组展示出类似行为的对象来形成类。
例如:将具有共同责任的事物划分为一组,让超类包含一般责任,子类含特殊行为
根据系统功能:
确定系统行为,行为分配至系统的各部分
谁发起活动、谁参与活动
扮演重要角色的发起人和参与人被确定为对象à将行为职责分配到对象上
功能点思想:某种输出、查询、输入、文件或接口。系统外部可见、可测的行为
3) 领域分析
咨询领域专家,构建一个通用的模型草稿
检查领域中原有的系统,以一种通用的格式展示出这方面的理解
咨询领域专家,确定系统间的相似和差异
精化通用模型,以包含原有的系统
垂直领域分析(许多类似的应用)
水平领域分析(同一应用的相关部分)
最终用户<->开发者(领域专家的作用大)
4) 用例分析
前三种都非常依赖于分析师的个人经验。
在需求分析时应用。
用户、领域专家、开发团队列出基本场景->分析场景(故事板)-> 参与场景对象、责任、协作方式(A调B的操作)->次级场景
5) CRC卡
场景分析方式。
Class:销售类 |
|
说明:完成一次销售 |
|
职责: |
协作类: |
创建商品 |
商品类 |
计算总价 |
商品列表类 |
创建支付 |
支付类 |
计算找零 |
无 |
6) 非正式英语描述
写下问题的英语描述,名次作为候选对象,动词作为对象的候选操作
评价:简单但不严格
7) 结构化分析
作为OOD的前端,不鼓励。有先验的算法表示法污染设计的风险。
(1) 从数据字典分析开始,分析模型的上下文背景图。对象来自于环境、输入输出、管理的产品、服务和其他资源
(2) 由数据流图,候选对象:外部实体、数据存储、控制存储、控制转换;候选类:数据流、控制流
数据转换:已有对象上的操作,或新对象的行为
(3) 抽象分析:实践中很难成功应用。确定中心过程,跟踪进入和离开的数据流,对遇到的过程和状态分组
关键抽象是一个类或对象,它是问题域词汇表的一部分。给出了问题的边界,突出了系统中的事物。
机制:描述对象协作的结构。关于一组对象如何写作的涉及决策。代表了行为的模式。
发现:领域专家所使用的抽象,问题词汇表的一部分,如ATM的客户提到账户、存取款
发明:不属于问题域,如数据库,列表,队列等。是具体设计的结果
1) 精化关键抽象
判断抽象的品质:
低耦合(高扇入、低扇出)
高内聚
充分性(够用,最小接口)
完整性(所有方面,通用)
基础性(访问底层才能实现的)
详细设计后再编码
设计的增量、迭代式发展:提子类、提父类、函数上移、下移等重构手段
2) 命名关键抽象
对象用合适的名词词组:shape
类用常见的名词词组:Shape
名称应该是领域专家使用和认识的名称
修改操作用主动态动词词组:draw,moveLeft
选择操作表示出查询的意思,或用be动词:extentOf,isOpen
风格统一
选择机制时考虑因素:成本、可靠性、生产性、安全性等
客户违反接口不对;对象行为超出机制打算提供的行为也不可忍受。
关键抽象反映了问题域的抽象,机制是设计的灵魂。
类的接口设计是一种战术决策。
1) 机制即模式: 惯用法、框架
2) 机制示例: MVC