类-职责-协作作者建模——《软件工程:实践者的研究方法》第八版

        类。在本章前面已经说明了识别类和对象的基本原则。类的分类可以通过如下分类方式进行扩展：

         •实体类，也称作模型或业务类，是从问题说明中直接提取出来的例如 FloorPlan 和 Sensor)。这些类一般代表保存在数据库中和贯穿在应用程序中（除非被明确删除）的事物。

         •边界类用于创建用户可见的和在使用软件时交互的接口（如交互屏幕或打印的报表)。实体类包含对用户来说很重要的信息，但是并不显示这些信息。边界类的职责是管理实体对象呈现给用户的方式。例如，Camera Window 的边界类负责显示 SafeHome 系统监视摄像机的输出。

          ·控制类自始至终管理“工作单元”。也就是说，控制类可以管理：（1）实体类的创建或更新；（2）边界类从实体对象获取信息后的实例化;（3）对象集合间的复杂通信；（4）对象间或用户和应用系统间交换数据的确认。通常，直到设计开始时才开始考虑控制类。

        职责。在 9.2 节和 9.3 节中已经说明了识别职责（属性和操作）的基本原则。Wirfs-Brock 和她的同事[Wir90]在给类分配职责时建议了以下 5 个指导原则。

1.智能系统应分布在所有类中以求最大程度地满足问题的需求。每个应用系统都包含一定程度的智能，也就是系统所知道的以及所能完成的。智能在类中可以有多种分布方式。建模时可以把“不灵巧”(Dumb)类（几乎没有职责的类）作为一些“灵巧”类（有很多职责的类）的从属。尽管该方法使得系统中的控制流简单易懂，但同时有如下缺点：把所有的智能集中在少数类，使得变更更为困难；将会需要更多的类，因此需要更多的开发工作。

2.每个职责的说明应尽可能具有普遍性。这条指导原则意味着应在类的层级结构的上层保持职责（属性和操作）的通用性（因为它们更有一般性，将适用于所有的子类)。

3.信息和与之相关的行为应放在同一个类中。这实现了面向对象原则中的封装，数据和

操作数据的处理应包装在一个内聚单元中。

4.某个事物的信息应局限于一个类中而不要分布在多个类中。通常应由一个单独的类负责保存和操作某特定类型的信息。通常这个职责不应由多个类分担。如果信息是分布的，软件将变得更加难以维护，测试也会面临更多挑战。

5.适合时，职责应由相关类共享。很多情况下，各种相关对象必须在同一时间展示同样的行为。例如，考虑一个视频游戏，必须显示如下类：Player、PlayerBody、PlayerArms、PlayerLegs 和 PlayerHead。每个类都有各自的属性（例如 position 、orientation、color 和 speed)，并且所有属性都必须在用户操纵游戏杆时进行更新和显示。因此，每个对象必须共享职责 update 和 display。Player 知道在什么时候发生了某些变化并且需要 update 操作。它和其他对象协作获得新的位置或方向，但是每个对象控制各自的显示。

           协作。类用一种或两种方法来实现其职责：（1）类可以使用其自身的操作控制各自的属性，从而实现特定的职责；（2）类可以和其他类协作。Wirfs-Brock 和她的同事[Wir90]这

样定义协作：

协作是以客户职责实现的角度表现从客户到服务器的请求。协作是客户和服务器之间契约的具体实现……如果为了实现某个职责需要发送任何消息给另一个对象，我们就说这个对象和其他对象有协作。单独的协作是单向流，即表示从客户到服务器的请求。从客户的角度看，每个协作都和服务器的某个特定职责实现相关。