OO Unit4 & All ViewBack
第四单元相关
综述
本单元重点从编程的结构上面转移到了对于UML的使用以及理解上。
总体来说，本单元的三次作业相互之间关系不大，更像是分别实现了三个部分然后拼接在了一起。
所以虽然三次作业的架构有所变化，但都是外接了新的部分使整体进行了扩充。
当然本单元还有一个难点（对于我来说），是对于Java的理解。
此外为了方便本次的情况处理，保证所建模的模型均可以在不与前面所述的规定相矛盾的情况下，在Oracle Java 8中正常实现出来。
查阅Java到底什么能干什么不能干，仿佛打开了新世界的大门……
第一次作业
本次作业只涉及到了UML的类图。
虽然课程组的官方包已经对输入的json格式进行了一层包装，但明显对于图的描述，这种简单包装是不够的，因此自己对非叶子结点进行了二次包装，使他们能够存储其他节点。
其中包装后的MyUMLClass和MyUMLInterface继承自MyNode，以减少代码的重复——事实上后来两次的官方包同样进行了这种处理。
复杂度主要出在递归查询顶层父类以及查询所有实现的接口这两个地方。对图的遍历复杂度高算是较为正常，当然自己优化也不够。
由于自己有点“瞧不起”测试点，自己最开始的DFS甚至没有判重也没有判断环路，导致强测一点CTLE。加入判重变为标准DFS后不再出现问题。（很是吃惊Java竟然真的可以环路继承……
第二次作业
本次作业新增了UML顺序图和状态图的查询。同第一次思路，对非叶子节点进一步包装。
复杂度因为查询本身简单故没太过增加。
另外架构方面，本来没有考虑设计reader包，而是把如今三个reader全部放入MyUmlReader中，但奈何写在一个文件会超过500行，格式检查过不去，故拆分。个人感觉写一起比较有连续性。当然拆分后亦可以说是各司其职。
第三次作业
本次作业加入检查。到了检查自己DFS技术的时候了……事实证明自己技艺不精，又改了好几遍。
当然在检查时候既然已经遍历过图了，那不妨加个缓存，免得之后查询图的时候再次遍历。
复杂度全部出在遍历上了。
总结
感觉这单元架构的灵活性也不是很强，毕竟编程难点更多在于理解以及对图的遍历。
当然老师曾说如果上个单元设计的架构好的话本单元可以直接复用上单元代码。自己虽然对图的遍历部分都单独设计了类来处理，但是类与类之间关系还是过于密切。主要是自己权衡了一下要不要更加注意减少耦合让某一类可以单独工作，但是对于本单元作业来说为了减耦合而去改设计并不划算（可能还是我懒？），比如自己找环（R002）和找重复（R003、4）会进行两种不同的DFS，后者会用到前者缓存，减耦合会影响缓存。所以我选择了“道理我都懂，但我不干”。
终章
对OO的理解
初
最初的理解着眼于了对象。一个对象是什么，这个对象能干什么。如此初级的理解，让我甚至认为Java的类和C的结构体没什么不同。当然，单就“面向对象”来说，C的结构体显然可以胜任，但其自身不够完美。
进
虽然一直说面向对象是一种思想，不是一种语言，但要说自己在课程中体会最多、学习最多的，还是Java这门语言。逐渐理解了Java程序在内存中的布局，理解了深层复制与浅层复制，理解了JVM的部分工作，也理解了Java为什么适合面向对象。
进一步，面向对象本身其实还包含着多种多样的东西。设计模式的学习，测试驱动编程的学习，规格化语言的学习……
当然，多线程也是我第一次接触，感触较深。
终
其实课程的结束并不意味着自己对OO的理解到达了完全体。现在自己只是更加熟悉OO的思想，能够更加合理地拆分程序，划分每一个类的任务。还有很多要更加深入的。
当然，回归本初，面向对象就是划分对象，每个对象干自己的事情。我们学习的，是如何规划“自己的事情”。
课程收获
- Java的深入理解。
即便上学期选修了Java课程，学期初的自己对Java也仍然是只知道语法。整个课程下来，多线程知道了，JVM也有了基础认知，虽然对于最初作为用来网络编程的Java来说，不学习其网络编程就不算会用Java，但对Java的熟练度还是大大进步了。 - 设计思想转变
现在自己看世界的感觉完全是OO的样子了……
当然，最大改变还是编程的步骤上，自己现在会选择先画架构再进行编程了。 - 测试思维初步训练
学会了更多的测试手段与方法。
学会了python……
改进意见
- 研讨课设计实际效益小
目前的研讨课分享的东西大部分来说没有意义。本班级除去“测试驱动开发”这一次分享让我学习到了新知识以外，其他感觉都是分享一些做作业必须用到而且是已经用到的东西，比如第三单元分享的算法，作业不用是无法完成的，却又在第三单元结束后长篇叙述。“死锁”这部分也是在OS课程有过详细讲解。 - 实验课不给反馈、实验难度高低不等
诚然实验介绍时候多数会给上一次实验的总结，但对于每个同学来说，知道全年级多少人过了几个点没有什么用处……
而且实验难度并不均衡。有些时候半小时完事，有些时候两小时做不完（服务器崩溃那次明显大家都没做完）。 - 互测应增加重复类型错误的判罚
当一个人拥有了自动评测机，你非常可能因为一个同质bug获得几十个错误数据，然后自己一次修改改了几十个bug（我室友的最高记录30+个点一次清零）。我们应当鼓励测评者分析bug类型。希望增加判定，在对别人的同质bug的hack次数过多应当进行惩罚（扣分），不然估计课程设计互测的目的也达不到。（当然如果互测本来就是用来刺激大家写自动评测机的话……
附：线上学习体会
感觉这个都被写滥了，毕竟连体育课都要写这个……
要说咱也没体验过线下的OO课，也没法比什么。不过我猜线下教学课程组应该某些方面会收敛一点……比如不会用问卷暴露些什么？
可能影响最大的就是和同学一起OO的难度增大了。相比之下倒也领略了各个老师的教学风格，有些课程停课以后OO的时间也更充裕了。
以上。
感谢课程组，感谢助教。
浙公网安备 33010602011771号