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

二、面向对象分析

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

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

 

 

    

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

（二）抽象关键类

1.获取关键类的表格

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

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

    怎么获取？

    请看下图

 

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

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

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

    1）关于关键类的来源：

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

    2）如何识别关键抽象

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

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

     

2.CRC卡进行职责分配

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

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

如下图：

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

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

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

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

    下面是关于CRC一点扩展：

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

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

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

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

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

转载于:https://www.cnblogs.com/tanqianqian/p/5975040.html