类职责协作模型

领域模型表示与问题领域相关的基本业务概念，领域建模的工作是，去发现那些表示与问题领域相关的事物和概念的类。领域模型的类职责协作（Class Responsibility Collavorator,CRC）模型是一组标准索引卡片的集合，这些卡片被分为三部分，如图4.2所示。类代表相似对象的集合，职责是类所知道或要做 的事情，协作者是一个类为完成其职责与之交互的其他类。

　　CRC模型被开发人员和用户成功地用于理解整个系统开发周期中面向对象的应用，CRC模型是一种惊人的用于领域建模的有效工具，也就是说为领域中的基本概念进行建模。CRC建模是一个迭代的过程：发现类、发现职责和定义协作者。

　　一个类代表一组相似对象的集合，一个对象是与所讨论的系统之中相关的一个人、地址、物品、时间或概念。类的名字出现在横跨CRC卡片顶端的区域，并且 通常是单个名词或名词词组，如顾客、图书和资源等。使用单个名词是因为每个类都代表单个对象的泛化形式，所以类名用单数而不是复数，类的名称还应该简要直 观。

　　发现类，从本质上讲是一项分析工作，因为它为应用程序确定构件。使用以下策略来发现潜在的类：（1）参与者是潜在的类；（2）确定客户；（3）跟踪资金流；（4）领域的术语概念是候选的类；（5）领域中的关键事件是潜在的类；（6）主要用户界面元素等。

　　类的职责是类知道的或要完成的事情。例如，顾客有名字、地址和电话号码，这是顾客知道的东西。顾客要借书和还书，这些是顾客要完成的事情。一个类知道 和要完成的事情构成了类的职责，重要的一点是，类能够改变它所知道的事情的值，但类不能改变其他类所知道的事情的值。换句话说，类只能更新它们自己的属 性，而不能更新其他类。

　　发现职责是需求分析的任务，因为它定义某个类是什么，而不管它是如何实现的。对象范型基于以类的形式表示数据（类知道的事情）和功能（类要完成的事 情）的组合，这也正是为什么CRC建模特别适合面向对象开发的原因。确定职责的一种方法是，应该问自己某个类需要做什么，即某个类必须执行那些功能。另一 种方法是问自己必须存储类的一些什么消息。

　　有时一个类要实现某一职责，但却没有足够的信息去完成该职责，就必须依靠与其他类协作来完成工作。协作通过以下两种形式之一完成：即对信息的请求或对 完成某项工作的请求。仅当类A为类B完成某些事情的时候，类A才显示为类B的协作者。这里需要理解的一个重要概念是，协作必须发生在一个类需要它自己仍不 知道的信息的时候。在面向对象的世界中，必须讲礼貌，去请求信息。这是与面向过程开发完全不同的思想，在面向过程的世界中，如果需要信息，把它拿来就好 了。虽然面向过程方法很直接，但它会导致代码难以维护。

　　在确定协作时，以下问题需要注意：
　　●对于任何协作，总是至少有一个发起者。换句话说，协作总是会从某个地方开始的。
　　●有时候协作者完成工作的主要部分。一个类发起一项协作，并不能说明这个类要完成大部分工作。
　　●为了完成一项协作，一个类必须与其他类协作，要减少不必要的转手，这样做通常会有更高的效率。
　　●可能会产生新的职责来实现协作。

　　定义职责和协作者是个高度迭代的过程。在确定职责的时候，必须永远记住两个问题。第一，有时确定的是并不会去实现的职责。第二，类的很多职责是需要通 过协作来完成的。注意，当一个类需要和其他类协作时，这意味着第二个类现在有了完成该协作的职责。换句话说，当发现职责的时候，需要定义协作；同时，当定 义协作的时候，常常会发现新的职责。这是CRC建模成为迭代的原因之一。