面向对象第四单元总结
面向对象第四单元总结
本单元架构设计
在本单元第一次作业中，由于实现要求只有类图，因而我直接在MyImplement类中实现了类图的所有功能。然而在紧接着的第二次作业中，引入了时序图和状态图。这三种图显然是相互独立的版块，因而需要各自抽离出新的类。由此，我又将第一次作业中实现的所有内容移到一个新类中。现在回想起来，第一次作业设计时就没有充分考虑可扩展性，而是为了写代码方便就直接在顶层中实现功能。
由于UML本身具有自己的树形结构，因而我本单元的层次设计也是完全按照UML本身的结构来实现的。层次管理中，有的对象可以直接借用官方包的elements包下的类来创建，而有的对象需要扩展功能，因而我自己实现了具有自己需求的类。
个人代码实现的层次架构和UML的树形结构一模一样，只是在个人需求上实现了部分而已。为了实现作业要求，在各个类中增加相应的属性和方法必不可少。比如classDiagraph实现了UmlClassModelApi接口，相应的需要承担各个查询方法，其中很多是针对类的查询。因此，ClassGraph有必要存储SingleClass的数据。为了方便查找，我建立了HashMap通过名字直接找到对应SingleClass。除了通过名字查找外，还有通过id查找的需求，因此我的ClassGraph还有id对应的HashMap。
还值的一提的是判断类里的重复操作。由于我的设计中，SingleClass使用容器管理自己的Operation，因此各个类显然应该知道自己的操作是否重复。因此，我直接使用HashSet管理Operation，并重写Operation的equals和hashcode方法，如此一来便能直接判断重复方法。
此外，时序图的UmlAttribute算是一个相对难的地方，因Attribute和Interaction是同一级，而Attribute被Lifeline这一更低的级引用。因此针对一个Lifeline，需要找到它的上级Interaction，再比较其ParentId是否等于这个Lifeline指向的Attribute的ParentId。
架构思维和OO方法理解
这半年的面向对象学习让我对“设计”这两个字有了更深刻的理解。面向对象本身就是考虑各个对象如何协作的编程方式，在实际编程中，我们仿佛是上帝，规定每一个物体的形状、能力以及运作方式。要想让这些物体运行得好，我们必须要仔细规划这些物体的特性。步行可以走到罗马，坐飞机也可以，那我们是否需要为各个物体配备一架飞机呢？正如上述所言，在实际编程中会遇到很多权衡，如何权衡也是我在这学期有所体会的内容。
我仍然记得读完第一次作业时的无力感。当时的自己完全不懂得层次设计，面对一个表达式完全不知道如何将其分解成一个个对象。然而，随着不断的学习与练习，在第三四单元的作业实现中，我看到题目后脑海里能很快地浮现出初步的关系图，然后再慢慢思考，用不了多久便能写出适合的层次架构。我最大的体会是，要将一个个对象如人类社会般看待。其实人类社会是很多协作关系的复杂集合，实际应用中需要的小的协作关系在人类社会中基本能看到缩影，然后通过类比，便能模拟出自己将要实现的框架。
至于OO方法，个人认为最突出的就是封装性。对象之间交互时只知道对方能做什么，而不会知道它怎么做这些。好比组装汽车，有的工人负责将最基础的零件组装成一个个模块，有的工人负责将这些模块再次进行拼装。其他的诸如多态，个人感觉只是方便编程的技巧，最核心的还是封装。我最大的体会就是在最后实现代码时，我不是一个方法一个方法写，而是先把类创建，然后填入这个类的属性和方法，基本写完调用关系后再填写每个方法。比如我在类中用到了很多private方法，这些就是我在实现方法的时候认为需要抽离出其他方法时创建的。
测试理解
在这四个单元中，我每个单元都写了自己的评测机，但是第二、四单元只写了第一次作业的。测试部分主要在于如何获取数据。根据我多次随机生成的经验来看，这种方法的效果并不太好。纯随机很难遇到特殊情况，而大多数特殊情况才是测试的重点。但是第一单元相对就很少有特殊情况，因此我在第一单元的随机测试中对自己的数据生成比较满意。但是紧接着第二单元，个人感觉完全随机数据几乎没有意义，因为数据量小，只靠随机连同一层超载的情况都比较难，因而最终的效果一般，这也导致我后面两次作业都是自己构造数据。第三单元我都写了随机生成，同样针对最小生成树和最短路的强度太低。
我平时也会多次思考到底该如何进行测试。单纯靠随机数据强度太低，只靠自己构造又太麻烦。我联想到去年计组课程的测试，当时助教告诉我，可以按照指令的组成随机生成指令块来测试。那么在四个单元的测试中可不可以以“块”的形式来构造数据呢？我想应该是可以的。比如图，那么多指令完全可以分开测试，先加入人、组，然后以需要测试的指令的特点加入关系。比如要测生成树，就可以取出某一群人加入密集的关系。
当然，这些我在课下没有自己实现过，因为“指令块”光是想起来就感觉很难。希望今后能有机会学习测试方面的专业内容。
课程收获
收获主要在于思维理解方面，这些也在上文叙述很多。
其次是讨论课吧，我很享受在讨论课上和小组同学分享各自的理解，因为平时很少有这样的机会。在讨论课中我学到了吸收他人思维的闪光点，尝试融入到自己的理解中。但是感觉有时候小组讨论的时间太短不够用。
课程建议
- 感觉理论知识存在感低，大部分收获来源于实践中摸索，建议可以每周发布一点额外理论学习，比如java语言本身的特性、设计模式、架构练习等，在理论学习方面拓展一点。
- 改变博客形式，感觉博客只是这门课程表面的需要，并不能给每位同学带来实际的收获，比如我写这些博客真的是在博客作业布置后针对课程组的几个问题去写，而不是真正心有所感想抒发。一般来说，强迫的总结只是事后绞尽脑汁的编造。或许可以单纯以作业的形式回答问题，或者把博客作业下放到每周，一有想法就快点写出来。
- 课程网页不好用，建议当前栏目滑到任意位置都可以切换栏目（介绍、评测、互测之类的）。
- 讨论课的每个组总结的意义比不上其消耗的时间，因为总结大同小异，希望可以缩短每个组总结的时间，只总结各自独特的地方而不是讨论的所有内容。
