面向对象分析与设计——分类

4           分类

没有完美的类结构，也没有一组正确的对象。设计选择是许多竞争因素的折中。OOA提出了一些有用的、值得推荐的实践和经验法则。

4.1   正确分类的重要性

      确定类之间的泛化、特化、聚合等层次结构；识别对象交互的共同模式，发明机制；指导模块化。

4.1.1    分类的困难 

       发现一种秩序不容易，但一旦秩序被发现，了解并没什么难度。需要很多艰苦的工作才能设计出简单的架构。

4.1.2    分类的增量和迭代本质 

       分类难，最好通过一个增量式、迭代式的过程来完成
       初建，基于经验修改：新建子类、分解类、组织类、设计新类等
       为何难：不存在完美分类（视角不同则划分不同）；明智分类要创造性思维（品味问题） 

4.2   确定类和对象 

4.2.1    经典方法和现代方法

 1）  经典分类

  利用相关的属性作为对象间相似性的判据。（根据某一属性是否存在）
  考虑哪些属性，与领域高度相关。 

2）  概念聚集

  类（一些实体的聚集）的产生首先是形成类的概念描述，然后再根据这些描述对实体 进行分类 

3）  原型理论

  对象的类是由一个原型对象来代表，如果其他对象与它表现出重要的相似性，就被认为是这个类中的一员。

4）  应用经典理论和现代理论

  以上三种都可应用于OOA。 根据领域相关属性来确定类和对象。
  关注问题空间词汇表的结构和行为。接下来，按概念来聚集对象（或按概念来优化最初的基于领域的分类）
  关注协作对象的行为。接下来，考虑按关联度分类。

4.2.2    面向对象分析     

1）  经典方法

  类和对象：实物、角色、事件、交互
  数据库：人、地点、物、组织、概念、事件
  对象：结构、其他系统、设备、要记住的事件、扮演的角色、位置、组织机构单位 

2）  行为分析

              经典方法关注实实在在的事物，另一思路是关注动态的行为。
              更像概念聚集，根据一组展示出类似行为的对象来形成类。
              例如：将具有共同责任的事物划分为一组，让超类包含一般责任，子类含特殊行为

              根据系统功能：
              确定系统行为，行为分配至系统的各部分
              谁发起活动、谁参与活动
              扮演重要角色的发起人和参与人被确定为对象à将行为职责分配到对象上

              功能点思想：某种输出、查询、输入、文件或接口。系统外部可见、可测的行为

3）  领域分析

              咨询领域专家，构建一个通用的模型草稿
              检查领域中原有的系统，以一种通用的格式展示出这方面的理解
              咨询领域专家，确定系统间的相似和差异
              精化通用模型，以包含原有的系统

              垂直领域分析（许多类似的应用）
              水平领域分析（同一应用的相关部分）     

              最终用户<->开发者(领域专家的作用大)

4）  用例分析

              前三种都非常依赖于分析师的个人经验。
              在需求分析时应用。
              用户、领域专家、开发团队列出基本场景->分析场景（故事板）-> 参与场景对象、责任、协作方式（A调B的操作）->次级场景 

5）  CRC卡

场景分析方式。

Class：销售类
说明：完成一次销售
职责：	协作类：
创建商品	商品类
计算总价	商品列表类
创建支付	支付类
计算找零	无

6）  非正式英语描述

  写下问题的英语描述，名次作为候选对象，动词作为对象的候选操作
  评价：简单但不严格

7）  结构化分析

  作为OOD的前端，不鼓励。有先验的算法表示法污染设计的风险。

（1）      从数据字典分析开始，分析模型的上下文背景图。对象来自于环境、输入输出、管理的产品、服务和其他资源
（2）      由数据流图，候选对象：外部实体、数据存储、控制存储、控制转换；候选类：数据流、控制流
                数据转换：已有对象上的操作，或新对象的行为
（3）      抽象分析：实践中很难成功应用。确定中心过程，跟踪进入和离开的数据流，对遇到的过程和状态分组

 

4.3   关键抽象与机制

      关键抽象是一个类或对象，它是问题域词汇表的一部分。给出了问题的边界，突出了系统中的事物。
      机制：描述对象协作的结构。关于一组对象如何写作的涉及决策。代表了行为的模式。 

4.3.1    确定关键抽象 

       发现：领域专家所使用的抽象，问题词汇表的一部分，如ATM的客户提到账户、存取款
       发明：不属于问题域，如数据库，列表，队列等。是具体设计的结果

1）  精化关键抽象

              判断抽象的品质：    
              低耦合（高扇入、低扇出）
              高内聚
              充分性（够用，最小接口）
              完整性（所有方面，通用）
              基础性（访问底层才能实现的）

  详细设计后再编码
  设计的增量、迭代式发展：提子类、提父类、函数上移、下移等重构手段    

2）  命名关键抽象

  对象用合适的名词词组:shape
  类用常见的名词词组:Shape
  名称应该是领域专家使用和认识的名称
  修改操作用主动态动词词组：draw，moveLeft
  选择操作表示出查询的意思，或用be动词：extentOf，isOpen
  风格统一

4.3.2    识别机制

       选择机制时考虑因素：成本、可靠性、生产性、安全性等
       客户违反接口不对；对象行为超出机制打算提供的行为也不可忍受。
       关键抽象反映了问题域的抽象，机制是设计的灵魂。
       类的接口设计是一种战术决策。

1）  机制即模式：          惯用法、框架
2）  机制示例：              MVC