发现类---面向对象领域（Domain）的分析

翻译：王咏武

　设计过程简介

　　●　通过考察问题领域（Domain）来识别出对象和类
　　　　--　通常对象（Object）应该首先被识别出来
　　　　--　把对象分类就可以形成类（Class）
　　●　识别出对象之间以及类之间的关系
　　　　--　结构型关系（Structural relationship）
　　　　--　协作型关系（Collaborative relationship）
　　●　分配职责
　　　　--　依据协作型关系分配
　　●　不断重复（Iterate）上述过程
　　●　应该为问题领域建模，而不是为解决方案（Solution）建模

　职责驱动的设计

　　●　是面向对象分析最广泛采用的方法
　　　　--　基于"客户机/服务器（Client/Server）关系
　　●　通常“客户机/服务器”有两种含义：
　　　　--　用于分布式系统，服务器提供对共享资源的访问，客户机提供用户界面
　　　　--　用于面向对象系统，服务器是提供服务的对象
　　　　--　我们使用第二种含义
　　●　客户机和服务器合作完成任务
　　　　--　一个对象可以在一种关系中是客户机，而在另一种关系中是服务器
　　●　服务器的职责是提供某些服务
　　●　通常，一个对象的行为应该是确定的

　CRC卡

　　●　CRC方法为每个类制作一张索引卡，卡上标明该类的职责，以及完成每个职责需发生关系的其他类。在卡的背面写上对该类的简要描述
　　●　在下面的例子中，为了完成职责"Do something"，类Foo必须和类X和Y协作（发送消息给它们）

　实例："小棍"游戏

　　●　该程序是一种计算机上的两人玩的游戏。有一些按行排列的小棍，当游戏开始时，这些小棍按照如下排列：
　　　　　　　　1：|
　　　　　　　　2：| |
　　　　　　　　3：| | |
　　　　　　　　4：| | | |

　游戏规则：

　　●　游戏者依次进行，每人每次可以从一个非空行拿走一个或多个小棍，拿到最后一根小棍的游戏者输
　　●　游戏开始时，以及每次移动后，程序会显示游戏的状态，哪个游戏者将进行移动，他想移动的那行的小棍数量，以及他想移动的棍数
　　●　当移动非法时程序会提示用户（例如：希望移动的数目超过该行中的现有数量）
　　●　思考：
　　　　--　提取对象和类
　　　　--　使用CRC卡
　　　　--　谁应该负责跟踪游戏者的移动次序？

　行（Row）的CRC卡

　寻找对象和类

　　●　从需求/用例说明书开始，列出所有的名词，这些都是初始的候选对象和类
　　　　--　对每个候选对象，建议形成一个类
　　　　--　确定概念上和物理上的实体（Entity）
　　　　--　消除重复（代表相同事物的名词）
　　●　细化候选类，代表一个类的初始状态的名词应该是该类的属性
　　　　--　形容词可能是属性或子类
　　　　--　分离大而复杂的类，合并过小的类
　　●　寻找关系
　　　　--　列出所有的动词，它们是主语名词所代表的类的候选行为或职责
　　●　剔除系统外的事物
　　　　--　明确什么是系统的一部分
　　　　--　用户不应该是系统的一部分
　　●　问问自己：
　　　　--　为了使软件在未来易于扩展需要什么样的底层结构（Infrastructure）？
　　●　注意：好的流程有助于创建好的模型

　从问题域（Domain）到模型（Model）

　　●　每个真实世界的系统应该按下列几个明显的问题域设计：
　　　　--　业务问题（Business problem）
　　　　--　数据的持久化（Persistent）存储
　　　　--　用户界面
　　　　--　系统上下文（Context）
　　　　--　功能划分
　　●　注意：不要混淆不同问题域中的职责

　分层的架构模型

　模型中的物理实体

　　●　对于控制物理设备的软件特别重要，即什么情况下软件需要为物理对象提供一个好的模型
　　●　OO编程起源于用一种好的方式写一个模拟器，即程序试图精确地再现某些真实的物理流程
　　●　例子：
　　　　--　问题域实体（Entity）：汽车、飞机…
　　　　--　系统实体：打印机、调制解调器、传感器、制动器…

　模型中的概念实体

　　●　优先权，访问权限，数据格式转换，交易管理，内存管理，错误管理，工作流，数据结构（图、树、队列、堆栈、哈希表），数学对象，应用，底层结构

　建模类

　　●　动物
　　　　--　狗
　　　　　　※　德国牧羊狗
　　　　　　※　狮子狗
　　　　　　※　野狗
　　　　--　猫
　　●　磁介质
　　　　--　磁盘
　　　　--　磁带
　　●　按照自然分类通常会形成好的继承树

　建模对象组

　　●　游戏布局
　　　　--　行（Row）
　　　　　　※　小棍
　　●　集团
　　　　--　公司
　　　　　　※　部门
　　　　　　　　◆　雇员
　　●　对象的组应按照组合（Compsition）或聚合（Aggregation）关系建模，集合（Collection）是一种特殊的组

　建模执行（Executive）或控制（Controller）实体

　　●　通常需要一个对象来管理（coordinate）其他对象。由需求说明书中的被动语态的动词暗示
　　●　例子：事件管理器、游戏裁判

　建模你必须调用的模型外的事物

　　●　这一点在真实世界中非常重要
　　●　例子：
　　　　--　遗留代码和数据源
　　　　--　操作系统
　　　　--　第三方软件包
　　　　--　系统接口
　　●　标示外部事物提供的服务
　　●　生成提供服务的对象
　　●　考虑为远程服务提供一个代理（Proxy）对象来封装所有的分布式通讯

　检查你的类

　　●　每个类都应该有一个清晰的、易于理解的名字，这个名字应该听起来象一件事物，而不是一个功能
　　●　每个类都应该有一个清晰的、易于理解的意图，该意图能适用于它的所有子类
　　●　相似但不同的类建议用继承，或者有可能的话代理到一个第三方的共享类
　　●　当多个类有继承关系时，它们才可能相互覆盖（Overlap），否则类之间不可能有覆盖关系。此时一个类完全覆盖其它的类
　　●　不同的类可能合作来完成职责
　　●　类应该有语义相关的属性和方法

　结构型关系

　　●　组合
　　　　--　B是A的一部分
　　　　--　A拥有B
　　　　--　A包含B
　　　　--　A拥有B的一个集合（Collection）
　　●　子类/超类
　　　　--　A是B的一种
　　　　--　A是B的泛化（Generalization）
　　　　--　A是B的特殊情况
　　　　--　A的行为象B

　协作型关系

　　●　A依赖于B
　　●　A使用B
　　●　A代理B
　　●　A需要B的帮助
　　●　A通知B
　　●　A和B地位相同

　职责和协作

　　●　职责：
　　　　--　一个类的实例提供给其他对象的服务
　　　　--　一个类的所有实例有相同的职责
　　　　--　职责包括：
　　　　　　※　执行动作（方法、行为）
　　　　　　※　维护和提供信息（状态、属性）
　　　　　　※　约束条件
　　●　协作：
　　　　--　客户机/服务器关系
　　　　--　协作是某一个类调用其他类来协助完成职责

　职责驱动的设计

　　●　类的职责定义了它的公共接口
　　　　--　浏览用例，寻找对象间的交互
　　　　--　对这些交互，确认客户机/服务器关系
　　　　--　每个交互暗示着服务器类的一个职责
　　　　--　从客户的角度用一个短语来表达职责，这就是支持该职责的服务器类的方法的名字
　　　　--　如果需要的话创建新的类
　　　　　　※　大的职责暗示服务器类应该把一些工作委派（Delegate）给其他类
　　　　　　※　如果一个客户需要不属于任何一个已存在的类的服务时，创建一个新的类

　分配职责

　　●　从这一步开始思考程序如何工作
　　●　铺开所有信息，行为和接口
　　●　尽可能的描述职责
　　●　保持信息的独立
　　●　职责可以被共享或代理
　　●　拿不准时，创建新类或删除旧类
　　●　没有任何职责的类是多余的
　　●　当你的设计太复杂时就重构它
　　●　检查设计看是否能支持所有的功能
　　　　--　按照用例，模拟模型的行为
　　●　不断迭代，重复

　实例：微波炉模拟器

　　●　需求描述：
　　　　--　微波炉通过微波照射来加热食物，用户使用键盘设定加热时间和微波功率，键盘上还有一个开始按钮。当时间到时，微波炉会停止并且响铃。如果门打开微波炉也会停止。假设微波发生器能够控制电子速调管在一秒的工作周期中工作
　　●　请为该系统寻找类

　微波炉－用例

　　●　设置时间
　　　　--　用户输入一个数字，然后按设置时间按钮
　　　　--　系统显示剩余的时间
　　　　--　系统设置时间
　　●　设置微波功率
　　　　--　用户输入一个数字，然后按设置微波功率按钮
　　　　--　如果数字不在1－10之间，什么也不做
　　　　--　系统显示功率级别
　　　　--　系统设置微波发生器
　　●　开门
　　　　--　停止时间计数
　　　　--　禁止微波发生器生成微波
　　●　关门
　　　　--　启动微波生成器
　　●　按开始按钮
　　　　--　如果门是关闭状态
　　　　--　开始计数
　　　　--　当时间大于0，生成微波
　　　　--　不断显示剩余的时间
　　　　--　当时间等于0，停止并响铃

　微波炉－类

　　●　微波炉
　　●　微波发生器
　　●　计时器
　　●　时钟
　　●　键盘
　　●　开始按钮
　　●　门
　　●　铃
　　●　其它按钮：清除，数字0－9，设置时间，设置微波功率
　　●　电子速调管
　　●　显示器

　微波炉－架构

　　●　用户界面中有三种类型的事件：
　　　　--　按钮被按下
　　　　--　门被打开或被关上
　　　　--　从时钟芯片来的计时事件
　　●　我们不想持续检查门来看它是开还是关，也不想持续检查时钟来看已过去多少时间。一种办法是当门打开或关上时，或时钟走过一个单位时，通知微波炉
　　●　事件驱动的架构好于轮询的架构
　　●　先假设你感兴趣的事件会造成你的类里的方法被调用。先不管如何来实现这一点
　　●　我们希望微波炉的所有部件（计时器、键盘等）能被其他种类的炉子重用。当然微波炉本身不能被重用，因为它和其他种类的炉子不同
　　●　按钮类没有系统控制的职责。我们会保持按钮类简单，它只有一个统一的接口函数：Push()。再次强调，我们希望有一个可重用的设计。因此，我们不想让按钮类关心系统中的其他部件

　微波炉－职责

　　●　微波炉本身：
　　　　--　知道系统的状态
　　　　--　把按钮命令职责委派给聚合对象
　　　　--　当门打开或关上时得到通知
　　　　　　※　关闭微波发生成器
　　　　--　当时间减到0时得到通知
　　　　　　※　关闭生成器
　　　　　　※　响铃
　　　　--　当时间走一个单位时得到通知
　　　　　　※　更新显示
　　　　　　※　通知微波发生器
　　●　所有按钮：
　　　　--　被按时，送一个命令给微波炉
　　●　微波发生器：
　　　　--　知道功率强度
　　　　--　如果启动，按照微波级别生成微波
　　　　--　当时间走一个单位时得到通知
　　　　　　※　按照微波强度（1－10之间的整数）在一个微波周期激活电子速调管
　　●　计时器：
　　　　--　知道剩余的时间
　　　　--　计数
　　　　--　通知微波炉下列事件：
　　　　　　※　时钟走了一个单位（十分之一秒）
　　　　　　※　剩余时间为0
　　●　显示器：
　　　　--　显示剩余的时间
　　　　--　显示微波强度
　　　　--　知道并且显示键盘当前输入的数字
　　●　键盘：
　　　　--　按钮的容器类。注意：这是一个不确定的职责，从下一次迭代的模型中删除键盘类
　　●　门：
　　　　--　通知微波炉开门和关门事件
　　●　铃：
　　　　--　响铃

　微波生成器的CRC卡

　UML预览：微波炉

　　●　比较两种不同的微波炉系统的UML类图
　　●　注意：UML类图是静态的，所以它不能用来对系统的动态行为建模

　微波炉类图1

　　●　轮询架构
　　●　工作良好，但是…
　　●　需要两个线程
　　●　高度的对象耦合
　　●　复杂
　　●　键盘不可重用
　　●　计时器不可重用
　　●　…

　

　微波炉类图2

　比较两个微波炉模型

　　●　模型2有一个微波炉类（Mediator设计模式的一个例子），注意各部件之间的协作非常简单，因为它们是松散耦合的，所以更独立
　　●　模型1使用轮询架构，而模型2采用事件驱动
　　●　模型2根本没有一个键盘类，因为该类没有任何职责，但是在模型1，它有职责
　　●　模型1和模型2处理10个数字按钮的方式不同
　　●　模型1有一个秒表（StopWatch）类
　　●　模型2不但简单而且更灵活

　词汇表

　　●　问题域　　　　　　　　　　　　　　　　　　　Domains
　　●　职责　　　　　　　　　　　　　　　　　　　　Responsibilities
　　●　协作　　　　　　　　　　　　　　　　　　　　Collaborations
　　●　代理，委派　　　　　　　　　　　　　　　　　Delegations
　　●　重构　　　　　　　　　　　　　　　　　　　　Refactoring
　　●　关系　　　　　　　　　　　　　　　　　　　　Associations
　　　　--　特化 / 泛化 / 继承　　　　　　　　　　　Specialization / Generalization / Inheritance
　　　　--　协作 / 聚合 / 组合 / 集合 / 依赖　　　　Collaborations / Aggregations / Compositions / Collections / Dependencies
　　●　组　　　　　　　　　　　　　　　　　　　　　Group
　　　　--　聚合 / 组合 / 集合　　　　　　　　　　　Aggregations / Compositions / Collections
　　●　遗留系统　　　　　　　　　　　　　　　　　　Legacy Systems
　　●　代理　　　　　　　　　　　　　　　　　　　　Proxies
　　●　中间人设计模式　　　　　　　　　　　　　　　The Mediator design pattern

---