哈工大软件构造lab3总结

软构的课程已经结束一段落了，如今回顾起来，收获颇丰。这篇博客主要是回顾一下lab3自己出现的一些问题，总结一下教训，帮接下来需要做实验的同学们避避坑。
第一点：不要拖延症，不要拖延症，不要拖延症。
不要开始的时候觉得时间还很长，不抓紧。！！！拖延症晚期的同学要注意！！！不要等最后一周的时候才开始写代码。这样会导致你难以很好地组织你的代码，出现了问题改起来也可能由于时间不充分，最后仓促上交。（大佬请忽略）
第二点：尽量按照要求来，让你提高复用性，就按照提高复用性的写法来。最开始的时候可能感到不适应，但写着写着你就会发现越来越适应，进展也会越来越快。可能如果不考虑复用性，最开始写代码时会比较容易，但——划重点：前期你偷的懒后面一定会加倍奉还。
第三点：测试代码一定不要等最后再去写，可能有一些同学不习惯、不喜欢写测试代码，都等到最后把程序写完了再最后去补测试代码。这样的弊端很明显，可能你感觉这样写进展很快，但是如果出现了问题，最后测试代码是个大红条，你还得返回去找这个问题出现在哪，有些应用类的错误不是出现在应用类本身，还需要一步一步找到最根本的问题出现在哪里。而且如果你的测试代码写的不够全面，会导致程序的潜在问题较多，别人使用的时候出错的概率会大大增加。
lab3的5选3问题，我选的是航班，高铁，课程表三个程序，开始的时候觉得这三个最好写所以选的这三个。（写完后感觉其实差距不是很大，选哪三个工作量上都不会差很多）我的src目录如下。

我是把时间类，资源类，位置类，状态类都单独分了出来。这样在planningentry类中三种场景都可以直接复用这几个单类型ADT，能够减少很多重复的代码。
关于三种场景的设计我的做法不太好，这里也是分享出来以防大家踩坑。
拿资源举例，我起初看航班，课程都是单资源类型的，所以我只定义了一个R类型变量存在common类中，然后flightentry类继承了common类。高铁因为有多个计划项所以我在trainentry类中又重新定义了一个list类型的变量，用来存储多个资源，没有使用common类中的R类型变量，看起来没有什么问题，在没做3.14change之前我感觉很合理，难度也不是很大。但3.14由于课程可以有多个老师上课，所以我不得不重新改动，将courseentry中也加入了trainentry类的关于资源的所有操作，虽然说只增加了四个函数，加起来也不过一百行，不过这里面所体现的问题却是值得思考的，我开始为了偷一下懒感觉都按照trainentry去写太麻烦了，所以没有这样去写，最后再去更改时又额外写了好几个test测试函数，而且看起来代码也不美观了，一点懒也没有偷到，反而为自己增加了好多工作量。反之，如果我一开始都是按照trainentry这种多资源的场景去设计，在common类中直接用一个list保存资源，这样做就可以将关于资源的操作都写在common类中，不用在每个单独的函数中重新写一次，这样做才是更合理的做法。
同理，对于R类和Board类来说，也可以提取出某些共性操作，比如说get方法，显示board等。其他类使用这些函数的时候也方便delegation，对于尽可能的提高复用性所做出的思考或许才是这次lab3我收获最多的东西。将共性的操作都抽离出来，每个单独的ADT都只包括自己独有的、无法和其他共享的方法操作，这样会让自己的代码看起来很简洁，也能避免很多重复的工作，想要使用其他类的方法时，直接delegate到其他类，交给其他类去实现就好。
当我最终写完lab3回头再来看的时候，我发现那五个场景完完全全就是针对同一套标准制定而成的，老师刻意把每个场景在不同维度上改了一些属性，然后看起来有所不同。例如资源有些是单个，有些是多个，位置有些是单个，有些是2个，有些是多个，时间有些是1对，有些是多对。所以如果一开始就按照最复杂的那种类型去写，这样就完全可以保证自己的程序可以适应5个场景，而且3.14change就几乎不需要改动了。写完后想到了这种更好的设计，我有更改的想法，但看了一下距离周末截止还有不到3天的时间，我只好放弃这种更好的想法，这也是为什么我建议大家尽量在前期抓紧写一点，为自己后面争取一点时间。
最后建议我的学弟学妹们，最好在一开始的设计时就考虑到后面的变化，以及如果可以的话，直接就按照change后的版本去设计（emm，这样做应该不算违法实验要求吧）