OO第四单元UML总结及课程总结

总结本单元作业的架构设计

本单元作业的总体设计思路是，将元素在读入时重写为自己定义的类并建成根据name或id索引对象的hashmap，在类内进行处理封装出外界查询接口，外界函数根据hashmap索引类并调用封装好的函数。

总结自己在四个单元中架构设计及OO方法理解的演进

总体上看，我对面向对象思想的理解是在不断进步的，而架构设计也随着面向对象思想的理解的深入和多次架构设计失败的经历，变得更能够抓住重点、更具全局观。

第一单元

第一次作业完全没有可扩展性，在多项式的限制下为了合并同类项采用的存储方式导致第二次作业进行了重构。而第二次作业重点放在了解释器上，再加上完全没有理解考虑面向对象的核心思想，导致虽然所有的运算符都继承了Operator类，我只是用get()方法和if else讨论了每种运算符的求导，第三次作业在第二次作业递归下降的基础上进行了wrong format的判断，没有再动求导的部分。

第二单元

第一次作业实现了单部多线程电梯（现在再看当时的代码感觉不分包真不是好习惯），电梯部分使用状态模式，策略选用使用策略模式，整体上解析需求读入经由调度器分配给电梯，电梯在运行过程中实现捎带。但是第一次作业没有考虑到不同电梯的类型，后续因为懒惰直接另写了两个类。第一次作业也没有理清调度器和电梯内运行逻辑的关系，导致这部分逻辑混乱，用到第三次作业还是重构了调度。

第三单元

三次作业并不需要在架构设计上花费较多精力，在阅读官方给出的代码的过程中，可以感受到实现社交网络各项方法时类的逻辑关系层层递进，对理解面向对象的思想破有好处。此外，为完成作业的时间限制，单独写了并查集、平衡树，对外仅暴露处理后的查询接口。

第四单元

第四单元的作业更多参考了第三单元官方代码的实现方式，对读入元素的处理不是很符合面向对象的思想，而需要填写的函数部分在实现上则层层递进、层层封装，继承和接口的定义和实现整体上比较合理，方法上也没有过分依赖get()和set()。

总结自己在四个单元中测试理解与实践的演进

测试上由于精力和个人动力的原因没有投入过多，但仍然在历练下有一些粗浅的理解。

第一单元

较为幸运的是一直以来，我都有写一部分、测一部分的习惯，前两次作业写完后出现的bug都比较容易修改，白盒测试上力求构造较为全面的测试数据（参考了往届学长学姐的数据构造方式如覆盖分支条件），第三次作业在其他同学的帮助下写出人生第一个评测机和数据机（参考讨论区ch大佬的极端数据生成策略做了一些调整）进行了黑箱测试。

第二单元

这一单元测试上只局限于白盒测试。手动针对自己的代码构造了测试数据（如morning模式下我的电梯状态与到达人数相关，就专门构造临界人数看电梯的运行状况），但是强测数据50s后开始发请求让我明白我的思路还是没有打开，构造数据的时候除了看自己代码的易错处，还应当全面分析题中条件，构造极端合法数据。此外，分析测试结果也不应仅仅关注电梯上下人开关门的合理性，还应当关注电梯的运行是否符合调度来检验自己的调度是否被正确实现。

第三单元

首先，学习了部分测试工具Junit的用法。其次，第三单元的代码难度不在实现而在于对JML的理解，如果只是局限于自己的思路测试就很难发现理解上的问题，故我在这一单元和其他同学进行了积极的对拍（同时还欣赏了计组评测机如何经过简单改动成为JML评测机，进一步理解了架构设计的重要性）。最后，由于JML数据并不复杂且触发TLE逻辑简单，在构造极端数据时更加得心应手了，增加了测试的信心。

第四单元

延续了部分测试的好习惯，综合使用白盒测试、黑盒测试，积极对拍，可以说综合使用了三个单元以来积累的全部方法，由于基础不牢，第一次作业测出了很多bug，也都及时进行了修正，后续两次作业也吸取教训，bug逐渐减少。

总结自己的课程收获

• java基础和idea的使用

• 正则表达式及递归下降、多线程基础、JML语法、UML语法等知识点

• 架构设计上的solid原则和面向对象的思想

• 更强的抗压能力并且增强了未来完成困难任务的信心

立足于自己的体会给课程提三个具体改进建议

• 第一单元第一次作业感觉和后两次作业衔接不够好，是为了出题而出题的，建议直接换成简易版求导。

• 第三单元和第四单元都存在规则不明确需要后续不断通知修改的情况，建议在微信企业号做一个通知系统，确认所有同学都收到了通知，如果有人没有确认可以由助教单独在微信群通知。

• OO这门课是公认的下限高，为了避免过分的两极分化，课程组可以增加一些测试方法或小技巧 让所有同学们都有测试的意识，在这种过程中进一步提高自己。