BUAA_OO_第四单元作业总结

BUAA_OO_第四单元作业总结

本单元架构设计

1. 第一次作业

类图如下

第一次作业我的架构设计参考了讨论区大佬的层次化设计思路，即将UML_CLASS 、UML_INTERFACE作为第一层、类中的操作UML_OPERATION，关联UML_ASSOCIATION作为第二层、操作中的参数UML_PARAMETER作为第三层，分别建立MyClass等类，通过多次遍历传入的Umlelemet数组，建立起层次关系，存储需要的各种信息。这样做的好处是各个类的职责划分清晰，查询任务分别划给不同的类，不会出现一个类过于臃肿、几十个hashmap叠在一起的情况。然而这一次作业的问题是写缓存时深浅拷贝理解不清，导致强测出问题。

1. 第二次作业

类图如下

第二次作业的架构和上一次相同，对于新出现的UMLStateMachine以及UMLInteraction两类数据结构和相应的查询指令，采用上次的层次化设计，将StateMachine、Interaction作为一层，下属的State、Lifeline作为下一层，建立MyInteraction等类。对于模型的有效性检查，我利用继承和实现等关系作为边，类和接口作为结点建图，通过dfs求环路等方式解决。总体来说，有了好的架构，第二次作业是较容易完成的。

架构设计及OO方法理解的演进

经过了一学期OO课程的洗礼，我的架构设计经历了从无到有，从低端到中端，从不忍直视到像模像样的飞跃。

在第一单元里，我接触了架构设计的思想，尤其是层次化设计。第一次作业可以说是完全的面向过程设计，一个main函数解决所有的问题。而第二次作业中，我便有意地将各种因子分成不同的类，虽然最后证明这样做没有什么特别的便利，可扩展性也不强，但起码是新的尝试。在第三次作业里，我学习了老师提供的思路，按照PPT上的模型建立不同的因子、运算规则类，有了初步的架构思想。

第二单元中，我学习了工厂模式、单例模式等设计模式，并在代码里运用。第一次作业我仿照生产者消费者问题，将输入线程作为生产者，电梯线程作为消费者，控制器的设计使用了单例模式，作为托盘使用，但在具体实现中将业务逻辑全部交给了电梯执行，导致代码的可扩展性不好。第二次作业中，我沿用了上一次作业的设计思路，但将处理请求的部分交给控制器执行，保证了各个模块的独立性。第三次作业便继承了第二次作业的各项设计，新增了请求划分、限制人数、停靠楼层等新需求。这一单元的作业让我接触到了SOLID设计原则，尤其认识到了其中开闭原则和单一职责原则的重要性。电梯就只应做上下运动、开关门等原子操作，而请求的处理则应全部交给控制器，这样才能有较好的扩展性，不必要每次都重构代码。

第三单元是我翻车的一个单元。现在我回顾一下翻车的原因，发现跟架构设计、oo方法没多大关系，很多地方都是基本的算法和概念出了问题。这一单元是JML规格设计，根据规格写出相应的代码。但具体实现我认为和JML没有多大关系，字典序、拆点建图、dijkstra求最短路等都是数据结构问题，然而我在以上的部分都摔了跟头，深感自己数据结构课没上好。然而看了助教发的标程之后，我才发现自己的架构设计也很糟糕，针对一个求最短路并保存的问题，我是直接用了几个大部分代码都重复的函数运算，将一个图的边权改了又改，缓存也大体类似。但助教的程序让我发现程序还可以这样写，还可以分成数据结构层、图建模层、应用层这么多层结构，令我收获不少。

第四单元总体来说难度比较适中，在这一单元里，我充分感受到了好的架构设计带给人的便利。在第一次作业里，我将UMLClass、Interface作为一层，operation、association作为一层，parameter作为一层，下层的类作为上层类的一个成员存在，每个类里负责计算任务，并提供出相应的公有方法。这样做就好比搭积木一样，构造函数建立数据结构时先将顶层搭好，再一级级将成员插入，条理十分清晰。对比我身边同学对着20多个不同名字的hashmap debug，我充分感受到了架构设计的重要性。第二次作业在第一次的思路上，也是很容易就完成了。这一单元的坑是缓存的深浅拷贝，这令我第一次作业炸了锅，实在不应该。

测试理解与实践的演进

关于测试方面，我使用了人工构造测试数据、自动化测试、junit测试等测试手段。其中，人工构造数据和自动化生成数据是我利用最多的方法。

第一单元中，我基本上只是人工构造了一些边界数据，和同学交换了 一些容易出错的测试点，进行互测hack。在单元最后的研讨课上，感谢同学的分享，我了解到了对拍器的概念，并在第二单元进行了自动化测试。在第二单元里，我自己写了数据生成器，和其他同学进行了对拍，但由于互测时取消了种种限制，再加上可能个人数据生成的较弱，互测中没发现多少其他人的bug，自己的也没怎么发现。在第三单元里，第一次作业我过分低估了难度，自己构造了几个样例就觉得没问题了，但由于字典序理解错误，直接导致强测爆炸。经过这一次的教训，之后我都进行了自动化测试。在这一单元里我还学到了利用JMLUnitNG/JMLUnit进行JML规格上的检查，可以说保证了测试的严谨性。第四单元由于临近期末，仅仅是自己用staruml画了几个图进行了验证，没有自动化测试。在整个课程的学习里，一次次的翻车让我了解到了测试的重要性，针对每一个要求实现的功能都应有测试样例。

课程收获

对我来说，这学期的OO课程无疑是最为硬核的课程。每次经过一个单元的洗礼，我都觉得自己的灵魂得到了升华。在四个单元的学习里，我充分感受到了架构的重要性、测试的必要性，以及代码正确性优先的原则。遍历我每次翻车经历，大体上归为以下几类：想优化效率导致缓存写错、数据结构不过关概念理解错、以及赶时间交错了commit。老师上课讲到的关于航天系统内编程的经历也给了我很大启示，写代码一定要先保证正确性，然后再追求运行效率。测试时，随机生成数据不一定全面，找出别人问题的最好方法是一行行地读代码。同时，也要感谢老师和助教的辛勤指导，以及讨论区同学的无私分享，同学和助教的思路和代码设计给了我非常多的启发和借鉴，每次作业的标程也让我惊叹代码还能这样写，讨论区的大佬也时常写出一些java8的新特性，令我怀疑我们用的不是一种语言。课程已经结束，但我的学习尚未结束，在暑假和之后的学习中，我可能还会再次回顾gitlab仓库里的优秀代码，查看讨论区里大佬们的精妙思路。总而言之，OO课程的确令我的代码水平得到了很大的提升。

三个具体改进建议

1. 希望作业提交网站能够自己选择最终提交的commit，而不是自动拉取最后一次提交。我时常会出现提交的commit新增了许多bug的情况，而发现这一点时，已经是截止时间的前几十分钟，这时就要很狼狈地再次提交一次之前保证正确性的commit。这不仅有可能会超出10次提交限制，还有可能不小心交错commit。希望课程组能改进这一点，可以默认是最后一次提交，但允许自主选择供评测的已提交commit。
2. 希望提高中测难度。中测的数据普遍过弱，导致一些基本的正确性问题都发现不了。虽然这主要是写代码个人的责任，但还是希望课程组能够提高一些中测难度，例如将强测的前几个点放进中测，以便个人更早发现问题。
3. 希望增加PPT中的代码量。在OO课程的学习中，令我提升最大的就是阅读标程和其他人的代码。现在的PPT中确实有不少示例代码，但个人觉得还可以更多，甚至可以增加一些“代码观赏课”，请同学分享其代码的优秀之处。

转载于:https://www.cnblogs.com/codearning/p/11076736.html