机房收费系统（合作版）总结——技术篇（二）

墨蓝 2022-08-08 15:58 213阅读 0赞

# 二、面向对象分析 #

## （一）根据用例描述获取对象类。 ##

关于用例描述我上一篇已经讲解了用例的核心是用例描述，在用例描述里面，我们要根据用例来获取对象类。

![Center][]![Center 1][]

由上我们可以看到，我们按照用例描述分析出来了很多的对象，这些对象都需要用么，或者是到底用哪些呢？

## （二）抽象关键类 ##

### 1.获取关键类的表格 ###

刚才大家也看到了，对象很多，也是很杂乱，那应该怎么办呢？

所以我们要学会获取关键类。

怎么获取？

请看下图

![Center 2][]

按照上面确定关键类文档你肯定要问我你怎么知道要排除这个类的，而不是其他类的，或者你怎么知道排除原因的?

答：其实是通过CRC卡来过滤的。请看下一部分。

下面是关于抽取关键类的一点知识拓展：

1）关于关键类的来源：

确定关键抽象我觉得并不是从零开始做的，应该是最大程度利用资源，我们要尽可能分析出来对象，并抽取为关键类。很多人喜欢在分析对象按照：边界对象，控制对象，实体对象划分。（笔者也是这样）所以在抽取关键类的时候，笔者是在“实体对象”里面抽取的。所以关键抽象通常被称为实体类。

2）如何识别关键抽象

其实识别关键抽象并不是很复杂，主要有以下两点：

首先，从来源上找出关键抽象集合，并且做出相应的分配；其次，将被确定的关键抽象以类的形式加入简单模型去，为每个关键抽象做出文字说明。

### 2.CRC卡进行职责分配 ###

首先先了解什么是CRC卡，CRC卡的全称Class-Responsibility-Collaborator。翻译成中文就是类名、类的职责、类的协作关系，在这里，我把它用来作为过滤候选关键抽象，确定系统要处理的核心概念。

要识别一个候选关键抽象是否是一个真正的关键抽象，应该先确定这个候选关键抽象担负的职责，同时是否有写作的关系。

如下图：

![Center 3][]

根据上图可以看到我已经分配了职责，协作，下面是步骤：

1) 选取一个候选关键抽象

2) 从用例描述里面查找职责和协作

3) 更新获取关键类的表格。

下面是关于CRC一点扩展：

问：为什么用 CRC 卡,而不用文档或者更先进的 UML 工具?

1)   卡片上面的空间很小,这样就可以防止我们给这个类太多的职责。如果一个类的职责太多的话(比如,超过 4 个) ,尝试以更抽象的方式去考虑一下,将职责划分。

2)  CRC 卡主要是用在探索或者讨论类的设计的阶段。如果我们觉得这个设计不行的话,我们既不用修改文档，也不用修改类图,只要把卡片丢了就行了。此外,一旦设计完成,我们就可以把所有的卡丢了。它们不是用  
   来做文档的。

3.如果我们觉得现在的卡片不合适,之前设计的比较好,我们只要简单的把之前的卡片拿出来组合就行了。 CRC 卡主要是用来快速的组织设计。我们不应该花很长的时候在做 CRC 卡上,也不要指望按照 CRC 卡的设计就一切 OK 了。在编码的时候,肯定还会不断的调整设计。将设计与编码结合起来,我们才能做出好而有效的设  
计。

对于 CRC 的使用方法并没有一个正式的定义,或者说,它要怎么用,并没有任何限制。我们不用太在意每张卡上写了什么,遗漏了什么。对于有些人来说,在每张卡上写个类名就足够了。而有些人认为,把职责也写在 CRC卡上,会帮助他们更好的思考。而有些人则希望把协作关系也写上去。我们也不用在意每张卡要跟哪张卡放在一  
起。一句话，CRC 是用来帮忙理清设计的思路，它不是 UML 图,也不是精确的类结构图。只要我们在处理这些卡的时候不断的讨论,我们设计的思路将会变成非常清楚。

[Center]: https://img-blog.csdn.net/20150920164835023?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
[Center 1]: /images/20220731/a9dc9982fb704f90b4b0004fe3528820.png
[Center 2]: /images/20220731/923aa3bd90224ee9b53f742a696abfcc.png
[Center 3]: /images/20220731/ea039de4366644bcb58d332e90a5c88f.png