2022面向对象设计与构造课程第四单元作业及整体总结
第四单元作业架构设计在本单元中，我们主要完成了设计并实现一个简单的StarUML解析工具的主体部分的任务。我认为本单元虽然没有互测，但强度并不落后于前面几个单元的练习，特别是在最后一次的作业上。总体来讲，我的思路与第三单元类似，对应UML中的每个实体元素，创建一个自定义的My类，并进行进一步加工处理。
第十三次作业
UML类图如下：
https://img2022.cnblogs.com/blog/2807072/202206/2807072-20220625213030470-1639506628.png
本单元的作业从一开始就不轻松，首先便是需要对UML类图各个元素以及之间的关联有相当准确的认知，才能构造出合适的框架和数据。在本单元作业中，我还是采用了如同第三单元中的做法，用HashMap将各类元素的id与其本身形成映射关系，从而降低时间复杂度。不过，由于传入的元素是乱序的，所以整个类图的构建需要分成两步来进行，第一步classify，用于将属于本类图的元素留下，并进行分类，构造出各自的实例。而第二步才是construct，确认各元素都已经被实例化以后，就能自底向上地进行添加，如向方法添加参数，向类添加属性、方法等。同时，对于泛化、实现等关系，也没有必要构造实例保留，直接在construct调用方法将实例联系起来即可。本次作业主要需要注意的应该是重复操作的判断，我的做法是使用HashMap记录代入参数不同类型的个数，可以发现，只要各类型数量完全相同，即可判断为重复操作，故参数也无需保留实例。
第十四次作业
UML类图如下：
https://img2022.cnblogs.com/blog/2807072/202206/2807072-20220625214125426-1436991029.png
第十四次作业中，又新增了顺序图、状态图相关的元素和查询操作。不过个人认为压力还是三次中最小的，因为基本都是相当于对第十三次作业架构的复用，没有什么特殊的花样，照着之前的架构扩展出顺序图、状态图即可。不过很可惜的是，在一个地方失误少打了.getName()，导致强测后面几个点丢失了大量分数，还是挺难受的。也可以看出，即使是很多次重复编写的代码，次数多了也还是容易出现纰漏，得更细心检查才行。
第十五次作业
UML类图如下：
https://img2022.cnblogs.com/blog/2807072/202206/2807072-20220625214602982-706006136.png
本次作业虽然架构与第十四次作业相差不大，但设计起来也相当复杂，主要就是由于添加了对于各种UML错误的判断。我原本一些不会用到的关系元素在构造完后我就不会保留了，但在这次作业中又要重新利用起来，为了尽可能不修改原本的架构体系，就基本直接在各UML图的construct过程中进行处理，并等待之后的检测。相对比较麻烦的就是R003与R004，也即循环继承和重复继承的判断，我一开始思索了很久算法，但并没有头绪，后面参考前辈的博客才反应过来直接暴力搜索也不会超时，于是便分别采用了dfs和bfs，对每个点进行一次全图搜索。对于循环继承，只要重新访问回起始点，就说明起始点必定在环中，而对于重复继承，如果重复访问到已经加入过队列的点，也就说明起始点存在重复继承。用这样比较暴力的方式即可完成本次的任务，不过还是希望能看到别人提出比较优秀的算法解法。
设计思维及理解演进
现在反观，在刚学习OO课的时候，比如第一次作业中，我感觉自己的理解还是相对生硬死板的，高内聚、低耦合的约束让我感到相对束手束脚，每次引用其他类的元素或者方法都惴惴不安，希望能够通过一劳永逸的分工解决一切问题。但经过二、三、四单元的训练，我逐渐感受到并非如此，面向对象并非是死板生硬的公式，同样需要结合一些面向过程的思维去实现，某个方法、某段代码出奇地复杂也是很难避免的，毕竟这也相当于局部性原理的体现，于是就要求我们有更高层次考虑的思维，权衡利弊，优化设计，我想这就是OO课希望我们获得的能力，风格检查中，方法、类的行数限制，既是对代码量的硬性要求，我认为同时也是对我们思维能力的软性要求，当代码复杂到一定程度的时候，就会引导我们进一步划分，并加以新的思考。OO课从整个过程来看，对我们理解面向对象的思维，学会进行面向对象的架构设计是大有所益的。
测试理解及实践演进
前两个单元的测试，可以通过手动攥写评测机来进行，但是实现的复杂度很高。而三四单元，则主要依靠与同学的对拍进行，实现的难度降低了，但同时可靠性也降低了。我想这也是在提示我们，在测试中，测试程序的复杂性低和可靠性高很难兼得。在不同的应用场景下，甚至有些难以预料的场合，都需要采用不同的测试方法进行测试，让程序尽可能地按照所预料的进行。不过，说实话，我认为OO课测试的强度确实是有些太高了，比方说手写一个评测机，在考虑周全的情况下，也基本与完成一次作业的工程量差别不大了，更何况每次作业的评测还需要根据需求同步地依次改进、迭代，任务量在OO本身代码复杂度就很高的情况下，进一步提升了。换句话说，我认为其实OO课光是测试部分的思想与工作量，甚至可以另外开设一门课程专门进行学习了，还是希望能够多协调、平衡一下任务压力。
课程收获
面向对象这门课程对我来说，算是第一门大量运用Java进行编程的代码，首先带给我的便是对一门语言更好的掌握，确实体会到Java比起像C语言之类的更加便捷，但同时也造成了能否恰当利用其内部提供的数据结构能够对整体架构和代码量产生很大影响的情况，还是需要通过多应用来熟悉。更重要的，便是面向对象的思维和设计方法，并不停留在表面的各种模式，而是真正从思维上形成了训练，每个单元一次又一次的设计和迭代对同学们的架构分析设计能力有着很大的要求，再加上强度较大的测试与互测环节，实在是相当硬的一门课程，不过这么高强度的训练所带来的思维方式上的提升也是其他形式所无法比拟的，确实让我们能够真正掌握分析需求、设计架构的面向对象编程能力。
改进建议
1. 个人认为，每个单元每次任务如果都做到同时完成作业，构造数据，编写评测这三项任务，那么工程量实际上是相当大的，每一项其实都能划分为一个作业进行，考虑到还有如操作系统等其他课程的学习与作业，可能很难保证每周都有这样的时间来确保正确性，希望课程组还是能够考虑一下任务压力的分配。
2. 互测环节中，大部分人还是采用批量评测机式的hack方法，我认为这还是一定程度上偏离了课程组设计的初衷，还是可以进一步缩小房间的规模，更进一步，我认为既然时间已经缩短到了一天，那么甚至可以每个人都只分配另一个人的代码，专门进行阅读与纠错，并对采用针对性数据详细指出对方错误的行为提出特别鼓励，将互相hack攻击的行为转化为帮助找错的行为，这样大家的体验可能会更好一些。
3. 中测与强测有时强度差距确实很大，再加上强测只有一次机会，无论测试程度如何，都会在强测前感到非常忐忑，基本相当于每周一次的测验，我认为还是给同学们造成了较大的心理压力。希望能够增加一定量对强测中错误的弥补措施，毕竟对大部分同学来说，都很难做到完全不出BUG，希望能尽量减少每一次丢分造成的心理影响。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]