BUAA OO U4总结&整体回顾

于恩泽-22371494 学生 2024-06-14 12:39:43

初闻不知曲中意，再闻已是曲中人。

本单元所实践的正向建模与开发

本单元重点是UML，强调的是使用UML在最开始就设计好这个程序的架构。

但是想一开始就理清楚一切显然不太可能，各种类的具体的方法和属性都完全无法保证实现出来没有问题。
因此，我的做法其实是将二者混合，一开始就只设计好类和它们必要的属性、很显而易见的方法等，对于拿不准的、后期实现实现中可能需要多次修改的，比如方法的参数等先不写。
因为我们设计其实主要设计的是类、属性、方法的功能，所以具体怎么实现，以及实现时需要补充哪些辅助方法，完全可以先不考虑（或者说只考虑可行性）。
在实现完成后补充好设计图（其实如果不考虑评测、后续开发、合作开发的话这一步似乎不是很必要）

虽然很多人感觉先画UML图会被处处掣肘，但是如果设计施工同时进行的话，以我来看确实是对作业有所帮助，毕竟我们其它单元的作业也得有个画草图的过程不是吗。

看起来有非常多的类，对吗？

主要的实体类其实和大家都差不多
- 有controller掌管一切，将各种请求接入对应的类和方法，类似酒店前台
- 有bookpool作为父类提供了管理书籍进出的功能（这种设计在第二次作业迭代时发挥了巨大的作用，修改存储方式只需要对这个父类下手即可）
- appointoffice, borrowoffice, bookshelf, dirftcorner等等都没什么特色，后三者继承了父类，但是自己的方法很少
我的studentList独立了出来使用单例模式提供了全局都可以访问的接口（没有提供直接访问的接口，保护隐私，只提供书的出入和信用分管理的接口）
可以发现有一些奇怪的小类CreditItem，LoanTerm,这些类似枚举，前者是各种事件信用分增减的具体分数，后者是各种书籍的借阅限时，将这些独立出来是因为多个类都需要这些数据，而在这些地方设计变量有点零散，使用魔法数会显得非常不专业且混乱，于是采用了这一方法。

通过这些设计，可以既减少迭代的工作量，又减少出错风险，还能提升整洁性（类分工明确），算是最整洁的一单元了。

也不算初识面向对象了，其实是对oop的增强。

第一单元主要就是递归下降法，但是我一开始完全不明白这个东西，参考了大量资料后完成了第一次作业才得以理解。因此，我的架构设计更偏向于仿照前人设计，在第二次及之后才有了自己的设计，比如设计出功能独立性很强的化简策略类和方法。

算是对复杂的问题的面向对象解法的初步建立，让我们能从复杂的问题中抽象出面向对象的概念，提升不可谓不大。

最印象深刻的一集

是真真切切地体会到了不好好设计生产者消费者会造成多大的麻烦：从晚上7点修bug修到中午2点，阎王都夸我好身体。
我的设计里reset相关的属性没有设计生产者消费者中的托盘的概念，选择直接互相访问，造成了非常非常大的耦合，也造成了到处都是锁，甚至四重从大到小不同层级的锁，非常棘手。

得益于上一单元的学习，这一单元各个类的功能划分的很清楚，但是类之间关系的设计出了大问题。虽然分数很高，但是看着飞满苍蝇（到处都是锁）的依托答辩我实在不好评价。这也引出了我们需要更好的设计，完成度更高的设计的需求。

如果我能在一开始就设计一个完成度适中的UML时序图该多好。

最安逸的一集

JML的最大好处就是它给出的设计要求已经非常详尽了，相比于文字描述，我认为还是JML要略胜一筹。

本单元主要学到的是设计与实现相分离，设计规范只是指明了要什么功能，实现方法取决于性能和工作量，颇有一种命题作文的感觉。

如果先学第四单元再学第二单元，也许我会做的更好

使用UML来设计简易初稿恐怕要比之前手稿设计要清晰太多了，通过在一开始设计好大致的程序框架，在后续实现中不断相互完善，我认为这才是真正健康的面向对象设计与构造，受益很大。

和LTC同学一起做评测机，但是四个单元评测只做了前三个单元，第四单元因为别的课压力起来了就仰仗野生的评测机了

第一单元
- 一开始是sympy化简法评测，但是随着作业复杂度增加做着做着发现行不通了，于是选择了对拍，通过代值求差判断正确性。
- 第二次作业偷懒没做文法测试，直接吃席两个点
- 后续采用的是使用鲁棒性为0的jar包进行测试文法（~~就像是吃一口尝尝有没有毒~~)，看看这个jar包报不报错。
- 典型的黑盒测试和对拍测试。
第二单元
- 突出一个需要多进程评测（因为评测一条就要50s+），用异步多进程能很好地解决这一问题。
- 这一单元主要是死锁或者时序造成的问题，因此极大程度地需要巨量测试
- 也是典型的黑盒测试
第三单元
- TLE是一个巨大的问题，针对性地设计了特殊的数据，并且做了benchmark，以防止特殊情况。
- 又偷懒没测一个小的功能(Tag容量有1111的限制），wa了一个点，马失前蹄。
- 为什么每次评测偷懒都会出事啊！！！
- 黑盒测试+受控数据的压力测试可以很好地应对这一单元。
第四单元也挺适合黑盒测试的，在构想中可以通过控制下一条输入信息生成的类别的概率来很好地进行高强度测试，但是可惜没做。

黑盒测试应该是用的最多的了，根据大家的实现情况进行受控生成的特殊数据以及压力测试也偶尔使用，评测机搭建进程也是受益许多，~~但是为什么每次偷懒都会wa点！真这么倒霉吗~~

在来6系前早已听闻OO课程的大名，没想到现在一回头，竟然已经过去了。

收获最大的其实是成就感（？关注点误

本年度电梯的困难已经超乎最初的想象，但是做完之后甚至分数很高而且回味无穷，这种挑战性带来了非常巨大的成就感。
真正的收获其实是面向对象的设计思维

这门课的程序、语言，都不重要，有了面向对象的抽象思维，把问题抽象出一个个的对象，设计合理的功能划分和对象间交互，这种思维是很有价值的。

哪怕不用java，用c也能写出带有面向对象思维的程序（点名os）。
收获到了代码熟练度

仅仅在电梯一单元就写了近3000行代码，对于代码熟练度的提升不可谓不大，以至于到第四单元写的时候昏昏欲睡也能肌肉记忆一般地完成。
测试方法的大拓展

在co期间就做过一系列像脚手架一样简陋的评测机，在oo真正系统性地做了评测机，真正掌握了高强度评测机的搭建全流程。没有GUI是一大遗憾，只能寄希望于后续的学习了。