面向对象-分类

  ↵

分类

分类是组织只是的手段。在面向对象设计中，认识到十五件的相似性让我们能够将共性放在关键抽象和机制中，最终导致更小的应用和更简单的架构。不幸的是，没有实现分类的金光大道。对于那些习惯寻找菜谱答案的读者，我们明确地指出，确定类和对象没有简单的诀窍。没有所谓的“完美”类结构，也没有一组”正确“的对象。像所有工程学科一样，我们的设计选择是对许多竞争因素的折中。

幸运的是，在其他学科中存在着大量有关的分类的历史经验、从一些更为经典的方法中，面向对象分析技术出现了，它提出了一些有用的、值得推荐的实践和经验法则，用于确定某个特定领域相关的类和对象。这些启发就是本章关注的重点。

正确分类的重要性

确定类和对象是面向对象分析和设计中具有挑战性的部分。经验表明，这种确定过程既涉及发现，也涉及发明。通过发现，我们主键从问题域的词汇表中识别出关键抽象和机制。通过发明，我们设计出泛华的抽象和一些新的机制，规定对象的协作方式。归根到底，发现和发明都是分类问题，而分类基本上是发现共性的问题。当进行分类时，我们寻找具有共同结构或表现共同行为的一组事物。

分类帮助我们确定类之间的泛华、特化、聚合等层次结构。通过识别对象交互中的共同模式，我们逐渐发明一些机制，成为实现的核心。分类也知道我们做出有关模块化的决定。

分类的困难

我们 将对象定义为有清楚定义的边界的事物。但是，将一个对象与其他对象分开来的边界常常非常模糊。例如，请看我们的腿。膝盖从哪里开始，到哪里结束？

分类的增量和迭代本质

明智的分类是很艰难的智力工作，最好是通过一个增量式、迭代式的过程来完成。Shaw曾指出，在软件工程中，“单个抽象的形成常常遵循某个常见的模式。首先，问题以一种随意的方式得到解决。随着经验的积累，人们发现某些解决方式比另外一些解决方式效果更好，一些好方法在人们之间口口相传。最后，有用的解决方案得到了更系统的理解，人们对它们进行编码和分析。

确定类和对象

1.经典方法和现代方法

从历史上来看，存在三种一般的分类方式：

经典分类

概念聚集

原型理论

1.1经典分类

在经典的分类方法中，“所有具有某一个或某一组共同属性的实体构成了一个分类。这样的属性对于定义这个分类是必要的，也是充分的”。例如，已婚人士构成了一个分类。一个人要么已婚，妖魔未婚这个属性的值足以确定某个人术语哪个人群。但是，高的人不会构成一个分类，处分我们可以一致同意以某个绝对标准来区分高矮这个属性。

在特定情况下应该考虑哪些属性，这与领域是高度相关的。例如，在汽车制造厂中，汽车的颜色对于库存控制可能是很重要的，但对于大城市里控制交通灯的软件来说，颜色就根本无关了。这就是为什么我们说分类没有绝对的标准，但是某个类结构可能比另一个类结构更适合某个应用。

经典分类法渗入了许多当代的西方思想，但是正如前面提到的高个和矮个的例子那样，这种方法并非总是令人满意。Kosko指出，“自然的分类会去想混乱：大多数鸟会飞，但有些鸟不会飞；椅子可以由木头、塑料或金属构成，几乎可以有任意条腿，这完全取决于它的设计者。对于任何自然的分类来说，在实践中似乎不可能得到一个属性列表，能够排除所有不在这个分类中的个例并包含所有在这个分类中的个例”。这是分类中真正的基本问题，概念聚集和原型理论试图解决这一问题。

2.概念聚集

概念聚集是经典方式较为现代的变种，主要源自于解释只是的表现方式的尝试。Stepp和Michalski指出，“在这种方法中，类（一些实体的绝技）的产生首先是形成类的概念描述，然后再根据这些描述对实体进行分类”。例如，我们可以声明像“一首爱情歌曲“这样的概念。这个概念超越了一个属性，因为任何歌曲的”爱情个区特质“不是可以经验性的测量的东西。但是，如果我们确定某个个区更像是一首爱情个区，我们就会把它放到这个分类中。因此，概念聚集更多地代表了对象聚集的可能性。

3.原型理论

在设计复杂软件系统时，经典分类和概念原型足以表达我们所需要的分类。但是，还要一些情况下，这些方法是不够的。这导致了原型理论，它主要来自于Rosch和她的同事在认知心理学方面的研究工作。

有一些抽象既没有清晰界定的属性，也没有清楚的概念。Lakoff解释了这个问题，“维特根斯坦指出，像游戏这样的分类不适合经典的方式，因为不存在所有游戏共有的属性。。。。虽然没有一组属性是所有游戏共有的，但是游戏的分类是按照维特根斯坦所谓的家族相似性来组织的....维特根斯坦还指出游戏分类没有固定的边界。分类可以扩展，新的游戏被引入，只要它们以某些恰当的方式与以前的游戏表现出相似性。这就是这就是这种方式被称为原型理论的原因：对象的类是由一个原型对象来代表的，如果一个对象与这个原型表现出重要的相似性，那么这个对象被认为是这个类的一员。

面向对象分析

分析和设计之间的边界是模糊的，但是每种活动关注的重点是不同的。在分析时，关注的重点是分析面临的问题域，从问题域的词汇表中发现类和对象，实现对真实世界的建模。在设计时，我们在模型中发明一些抽象和机制，为要构建的解决方案提供设计。

下面将分别讨论几种与面向对象系统有关的、经过实践检验的分析方法。

1.经典方法

一些方法学家提出了类和对象的许多不同来源，它们都来自于问题域的需求。我们将这些方法称为“经典方法”，因为它们主要来自于经典分类的原则。

例如，Shlaer和Mellor指出候选类和对象通常来自于一下来源：

实物   汽车、遥测数据、压力传感器

角色   母亲、教师、政治家

事件   着陆、中断、请求

交互   借贷、会议、相交

从数据库建模的角度，Ross提出了类似的列表：

人       执行某项任务的人

地点    人或物相关的区域

物        实实在在的物理对象或对象的分组

组织    正式组织起来的人、资源、机制和功能的集合，具有确定的任务，它的存在基本上与个人无关

概念    不可触摸的原则或思想，用于组织或跟踪业务活动和沟通

事件    发生的事情，通常是在某个日期和时间针对另外的事务发生的，或者是一个序列的步骤

Coad和Yourdon提出了另一组可能对象的来源：

结构      “是一种”或“组成部分”关系

其他系统  与应用进行交互的外部系统

设备      与应用进行交互的设备

要记住的事件  必须记录的历史事件

扮演的角色   用户在与应用的交互中扮演的不同角色

位置      对应用来说有重要意义的物理位置、办公室和地点

组织机构单位  用户术语的群体

行为分析

这些经典方法关注问题领域中实实在在的事务，但面向对象分析的另一种思路是关注动态的行为，将这些行为作为类和对象的主要来源。这类方法更像是概念聚集，根据一组展示出类似行为的对象来形成类。

领域分析

到目前为止，我们所讨论的原则通常适用于单个具体的应用。但是，领域分析试图确定在某个领域中所有应用都通用的类和对象，如病例跟踪、证券交易、编译器或导弹电子系统。如果在设计中存在的关键抽象有点疑惑，领域分析师可以提供帮助，指出这些关键抽象在其他相关系统中已证明有用，领域分析效果挺好，因为除了极特殊的情况之外，然健系统很少有真正独特的需求。

领域分析的思想首先是有Neighbores提出的。我们将领域分析定义为“”确定对象、操作和关系的尝试，领域专家认为这些对象、操作和关系对这个领域很重要。Moore和Bailin提出了下列领域分析的步骤：

咨询领域专家，构建一个通用的模型草稿；

检查领域中原有的系统，以一种通用的格式展示出这方面的理解；

咨询领域专家，确定系统间的相似和差异；

细化通用模型，以包含原有系统。

领域分析可以应用于类似的应用（垂直领域分析），也可以应用于同一应用的相关部分（水平领域分析）。例如，当我们开始设计一个新的病患监控系统时，理所当然应该调查已有系统的架构，理解当前使用了哪些抽象和机制，评估哪些对我们有用，哪些对我们没有。

用例分析

孤立来看，经典分析、行为分析和领域分析的实践都非常依赖于分析师的个人经验。对于大多数开发项目来说，这是不可接受的，因为这样的过程既不是确定的，也不能预测其成功与否。

确定关键抽象

1.细化关键抽象

当我们将某个关键抽象确定为候选者时，必须根据前一章中提出的测量指标来评估它。

Stroustrup指出，“通常这意味着程序员必须关注以下问题：这个类的对象是如何创建的？这个类的对象可以复制或销毁吗？在这样的对象上可以执行什么操作？如果对这些问题没有好的答案，这个概念可能在开始时并不清晰，也许最好是再仔细考虑一下这个问题和提出的解决方案，而不是立即开始针对问题进行编码。

对于一个新的抽象，我们必须将它放在已经设计好的类和对象层次结构的上下文中。实际上，这既不是自顶向下的活动，也不是自底向上的活动。Halbert和O’Brien指出，“当在一个类型层次结构中设计类时，并非总是从超类开始，然后创建子类。通常，会创建一些看起来不想死的类型，意识到它们是相关的，然后将它们的共同特点分离出来，放到一个或多个超类中。。。通常需要这样上上下下做几次才能得到一个完整和正确的程序设计。这并不是乱来的接口，而是基于经验的一种判断，即面向对象设计是增量式、迭代式的。Stroustrup也说过类似的话，他说，最常见的类层次结构的组织方式是从两个类中提取公共部分放到一个新类中，或者将一个类分成两个心类。

识别机制

考虑一辆汽车的系统需求：踩下加速踏板将导致引擎转得更快，放掉加速踏板将导致引擎转得更慢。驾驶员完全不关心这到底是如何发生的。只要能够提供这种行为，我们可以采用任何机制，所以选择哪种机制主要是设计时的选择。具体来说，下面集中设计都可以考虑：

一个机械连接装置，直接将加速踏板和燃油喷射器连接起来。

一个电子装置，连接加速踏板下的压力传感器和计算机，有计算机控制控制燃油喷射器

没有连接装置。邮箱放在汽车的顶部，利用用例让燃油流向引擎。然后的流速由油路的一个甲子来调节，踩下加速踏板将放松夹子上的压力，导致燃油流得更快

关键抽象反应了问题域的抽象，而机制是设计的灵魂。在设计过程中，开发者不仅必须考虑单个类的设计，还要考虑这些类的实例如何一起工作。同样，我们使用场景来驱动这个分析过程。