OO_Unit4暨学期总结

OO_Unit4暨学期总结

一、本单元架构设计

1.1 第13次作业架构设计

就我个人而言，这次作业应该是本单元难度最大的一次作业，原因在于陡然转向UML后，对UML各个元素的关系理解需要先下一番功夫，而接口所提供的信息则是言简意赅，边coding边学习的准确率得不到保证，只好硬着头皮先对这些概念做粗略的理解。

等到对UML元素稍有理解后，我准备采取一杆清台的架构来完成本次作业，即在实现接口的MyUmlInteaction类中用一些Map存储下各个元素之间的对应关系，以备在各个方法中查询。我在最开始不甚理解UML元素之间关系时还想在这种架构和以类为单位保存UML元素信息的方式之间反复横跳，之后选定了这条路之后我反而觉得UML元素之间的关系变得清晰起来。具体的UML类图如下：

1.2 14次作业架构

自己的架构用起来得心应手，因此稍加改造就延续到了第14次作业。将类图、顺序图和状态图的查询分成不同的类以减小耦合后，我发觉相比于13次对类图繁多的查询要求，这次的查询较少而且和类图查询有相似性，因此不费太大功夫就完成了这次作业。（尽管由于未考虑状态图没状态的情况导致翻车了一个点

1.3 15次作业架构

这次作业和14次一脉相承，在14次的基础之上，针对这一次要进行的预检查操作单独分出了一个类来减少耦合度。结构如下：

1.4 总结

在理解了UML图的元素之间的关系之后，我所采用的使用Hashmap来存储元素之间的映射关系的方式给我带来了许多便利：例如可以直接根据name查到id，可以直接知道某一id对应的所有父类id，给实现接口带来了方便。同时也带来了不便：HashMap<String, HashSet< String >>这样的数据结构使得我hashmap的get操作有可能得到空指针，而我还需要进一步遍历HashSet，就会引发空指针异常，这在第二次作业中给了我背刺。总体而言，我认为这种方法算是一种雏形的面向对象，只不过对象所拥有的属性我给表现为了map的映射关系，并且不让对象拥有方法，而是后续处理时自行处理；我的切身体会是这种方法的可拓展性不弱，但是需要对细节掌握的比较到位。

二、四个单元的架构设计及OO理解演进

2.1 第一单元

第一单元算是没有架构设计的典范，三次作业三种设计。第一次作业是彻彻底底的面向过程，一个class不到200行就处理完了所有逻辑；第二次试图面向对象，使用的工厂模式，但是其他部分仍然和第一次雷同，还是一个方法解决一切的思想；而第三次矫枉过正，彻彻底底放弃了前两次的架构，采用了表达式树的方式，同时对树的每个节点的类型都进行建模，但是由于缺乏经验，这种激进的做法反而给我带来了超乎想象的bug，最后疲于奔命。

在这一单元，我一点一点完成了从面向过程到面向对象的转变，虽然这种转变的结果并不是很好，但是这个过程中我逐渐感受到了面向对象的美感，也开始乐于使用面向对象的方式去思考问题。

2.2 第二单元

第二单元我开始刻意地用面向对象的方式考虑问题，采用了生产者-消费者模式加类观察者模式在三次作业中一以贯之。挪用之前总结中所说的“三次作业我都没有对第一次的架构做出巨大的修改，基本都是非常顺利地拓展第一次的架构。功能设计上，总调度-分调度-电梯的三级结构使得我在新增需求时快速分解需求，分配给三级结构中的每一级，从而实现拓展。”

在这一单元，我从多线程的角度理解了面向对象的合理性，如果没有面向对象这种思想，我们势必要陷入多线程之间繁复而不可预测的逻辑陷阱，而面向对象教会我们抽象出问题的来源：即这些逻辑都源自于不同线程之间的互动，因此我们只要把握住这些对象的特征即可。而例如生产者消费者模式，观察者模式都是对不同对象关系的合理抽象，给我们一个更规整的方式去运用面向对象的思想。

2.3 第三单元

第三单元的架构来源于课程组，课程组给定了JML的情况下我们更多地考虑是空间换时间和算法的改善，因此架构方面无甚可言。但是这也同时让我见识了好的架构是什么样子的，而自己如果写这一单元的架构又会是什么样子的。

这一单元给我的感受是团队分工带来的好处，好的架构师可以大大减少写代码时的头晕、恶心、不适，让我们愉快地写代码，同时我们自己也应该成为好的架构师，能够对项目的总体情况有所把握。

2.4 第四单元

第四单元的架构已经在上面说明了。这单元的重点在于对UML结构的理解以及各个元素之间的关系的把握。其实课程组颇有醉翁之意不在酒的意思，我感觉这单元设置的意图并不完全理解UML本身，而更多地是理解UML背后的面向对象思想。

2.5 总结

总体来看，OO的四个单元各有侧重点，第一单元是单个对象细分成多个对象，是总体和局部的架构关系；第二单元是一些同级的对象之间的彼此沟通和适应；第三单元看起来更像是纯粹的团队协作，只用我们安安稳稳实现接口即可；而第四单元是对多个同级和不同级的对象之间的关系进行处理。整体上对象的复杂度逐渐增大，我们从可以面向过程到只能面向对象。

三、关于测试的理解和实践

写代码不可避免地会带来bug，良好的测试是让自己心里踏实同时让别人对你的程序认可的最好手段。实际上，四个单元我都是采用黑盒测试，凭借海量的随机数据使得bug几乎无处遁形。

第一单元我采用exrex生成数据+sympy验证结果的方式构建了自己的评测机，效果显著。一些隐藏较深的，自己白盒测试覆盖不到的bug在评测机面前被乱杀，但是一些边界数据的情况却很难被测试出来，最后2、3两次作业不幸在互测中分别折戟一个点。

第二单元的测试方式类似，但是是在多线程的环境下同时测试不同的点，这里感谢@wpb同学提供的这种思路，有效地提高了跑出问题的效率，最后只在第七次互测中测出了一个小问题。同时我有效地hack了同屋人几次，也充分证明了这个评测机的效果。

第三单元更换了测试策略，因为没有找到合适的方式可以对结果进行客观的验证，只能通过对拍的方式找出不同，进而定位问题所在。而可能是因为本单元看起来比较简单，导致我的数据生成也比较简单，只考虑了正确的输入，而忽略了可能抛出异常的那些输入，最后导致第九次强测40分，算是不小的教训吧。

第四单元的测试策略同第三单元，出现的问题是考期的紧张导致我来不及写数据生成，最后第14次作业没有测试，也因此爆了一个点。

我对测试的理解在于：1. 测试告诉了我们在一些情况下程序的反应是否符合预期； 2. 测试代替了读代码debug具有更高的客观性。而测试的好坏就在于我们对情况的构建是否全面客观，黑盒测试是广撒网多捞，而白盒测试则是定点出击，一鸣惊人；两种方式相辅相成。我的bug没有测试出来更多的是在于白盒测试的不充分，自己对程序的边界情况考虑甚少。

四、课程收获

• 对java有了初步的掌握

• 对JML、UML这些工具有了一定的了解和实践经历

• 对容器和数据结构的再认识

• 学会了使用黑盒测试和白盒测试来验证程序的正确性

• 对多线程有了基本的认识

• 最重要的是，掌握了一点从面向对象的角度思考问题的方法，拥有了一点从对象到架构的能力

五、改进建议

以下三点重要度有先后之分，可以根据所写字数判断重要程度。

5.1 研讨课相关

就我个人感受而言，本学期的研讨课是OO课程设置上少有的败笔。如果说前两单元还偶有同学拿出干货进行分享，效果差强人意，那么之后的研讨课实在是让人不忍卒听，罚坐的煎熬多于分享的收获。灌水与读ppt齐飞，cnblog共runoob一色。说一句良莠不齐算是对研讨课质量最忠实的评论。当然，我并非是对分享的同学抱有极大的敌意，甚至于对其进行人身攻击，而是希望课程组能切实了解到研讨课的效果，给日后的学弟学妹们一个更好的OO学习环境。

究其根本，身为听众的我们实在缺乏选择的权利。好也罢坏也罢，我们除了寄希望于课程组提前的筛选能滤掉一些沙子之外，实在缺乏相应的手段能切实改善研讨课的质量。也许良好的评分机制能够改善现状，至少可以粗略地反馈每一次研讨课的效果，而不是等到学期最后才能在博客里含沙射影地表达自己的不满。

5.2 实验相关

一头雾水。每次实验都是晕着头来，晕着头走。一来实验也不作讲解，我们对自己答案的正确性非常迷糊；二来实验内容有点脱节，往往是在技术上考察我们对于某个工具或者某种模式的理解，对OO整体思想的把握实在缺乏引导性。建议明年的实验能够给学生更多的讲解，至少让大家真的从实验中得到点什么（目前是什么也得不到，因为只给问题不给答案同时无法验证是玄学领域的表征而非科学）。其次，实验内容和作业结合可以更加紧密，可以是一个缩小版的作业，给一些架构让我们拓展或者体验其可读性，可以让我们对架构的优劣有直观的感受。不然其实每单元大家偏安一隅，只抱着自己的架构闭门造车，收获甚微。

5.3 JML相关

东西是好东西，但是不可用的工具链和使得把JML投入实际应用实在是赶鸭子上架，学到的东西很少，甚至于算法被拉出来作为考察点，颇有偏离OO主题的意思。建议明年不要大张旗鼓地将JML作为一整个单元，可以进行有限的拆分，在预习和其他单元里稍微涉及JML的内容即可。

六、线上OO学习体会

线上的上课内容的学习可以自己掌控，可以多次看，也可以只看重点。线上的研讨课可能和线下区别不大，由于可以方便地共享屏幕可能效率更高。线上的讨论，课上讨论有时会尬住，但是课下的讨论活跃度更高了，尤其是课下的讨论也可以共享屏幕，彼此的交流更加直接。

总体而言，线上OO学习我觉得会比线下的OO学习效果更好，而且节奏主要在自己手中，更加舒服。