[BUAA OO]第一次博客作业

第一次作业

第一次进行面向对象的编程，不论是针对数据设计类还是对方法进行合适的归于不同类中，都不是很熟悉。所写出来的程序还是面向过程+有函数的类（虽然现在很大程度上感觉起来也是这样）。索性作业难度并不算高，完成的也算马马虎虎。公测都通过了，但是互测的时候被发现了一处笔误，少写了一个0，导致6位的测试样例无法正常读入。并且由于我的检测输入的实现并不是通过正则表达式，而是通过简单粗暴的有限状态机，故而第一周并没有完整学习正则表达式。虽然有限状态机的设计并没有出错，但是没有尽早学习正则表达式也给我后面的作业留下了隐患。

第二次作业

第二次作业对于电梯的设计要求并不高，除了一个需要排除同质请求的要求外，基本上跟遛狗一样，哪里有需求就去哪里。对于这样的设计要求，我设计了一个nextTime数组来存贮下一次这一条指令允许被点亮的时间开始点。在设计请求队列的时候，我设计的方法是与前项的请求时间比较，但是我忘记了对即时项数减一，故而导致对于时间逆序的判断恒为正。导致公测有两个测试点没有通过。由于我上次作业并没有按照正则表达式进行设计，我这次的正则表达式实际上是第一次设计。虽然没有出现录入时的爆栈，但是在字符转换为整形变量的时候没有用try-catch进行设计，从而导致转换的时候出现爆栈。真的让我很心痛…这让我明白按照公测树针对性的进行测试输入样例的重要性，debug的时候一定要覆盖到所有细枝末节，不能通过看和想来分析。

第三次作业

这次的作业险些血崩。由于要进行指令的捎带，也就意味着我上一次所设计的nextTime数组要做很大程度上的修改，不仅next的时间要随着指令的完成而变化，对于同质的判断也要随之而改变。这让我真的头疼不已。我之前了解到了第二次作业有的同学使用了模拟时间的办法进行设计。我认为这种想法真的挺好，我当时认为可以通过设计按钮（通过按钮的点亮情况指导电梯的移动、通过其亮暗的情况判断同质），来把复杂的对于指令的判断交给所涉及的模拟来进行。但是，这种初期看似美丽的想法往往会变得很坑。随着设计的进行，我发现，这种模拟实际上就是在设计一种有限状态机，不仅需要根据指导书中所提及的情况来进行完整的cover，而且对于主指令以及捎带指令的判断是无法避免的。因为指导书中要求对于不同的指令类型做不同的行为（再次务必要强烈吐槽一下，为什么一次开门不能解决所有问题…）故而，实际上，不论做哪种实现，对于主指令和捎带指令的判断和刷新是永远无法避免的。于是，我就经历了每天中午美滋滋的以为自己做完了，下午看客服群&再读指导书，发现了我的程序有无数个没有正确实现的点，然后debug到一点钟。这样连续了两三天…不过，这真的让我明白了老老实实按照指导书所要求的进行实现是多么重要。

对于大一的时候并没有参加6系魔幻课程数据结构的高工学生来说，面向对象编程是我们第一门大量码代码的科目。相比已经经历过洗礼的6系同学来说，我们的压力确实不小。不过，我想，学习是一个过程，纵使我们起步慢，我们也可以追。对于程序的设计和维护也是一步步进行的，希望我再接下来的无数个作业中能做的更好。