Part-0.3 对于博客
万事开头难,虽然说博客只是作业的一小Part,但是确实是自己第一次写一些关于编程方面思考的文章,之前从来都是写一个感性的小文章,思考思考人生啥的。而且我相信写好博客是很重要的一个环节,毕竟态度最重要嘛哈哈。俗话说七分看三分写,好的作品总是要一遍一遍推敲,所以这周二一整天的时间我都想用来做这件事情,不能说自己以后能坚持多久,但总归是迈出了第一步,就认真点吧。
Part-0.7 对于OO
说是面向运气编程,不如说是面向指导书编程。
毕竟分配作业是个技术活,像我这么非的人只能靠自己努力了。
顺利搞定OO的秘诀是心态,还有读懂指导书。
写作业最费的还是眼睛。
其实,相比于前三周的编程,最难的事情还是在要放清明假期的时候,稳住心态认真把博客写完吧。就像狼人杀一样,最有意思的事情还就是复盘了,因为这是你拥有信息最多的时候,这个时候如果都分析不好的话,那信息少的话更不可能Carry全场了不是嘛?所以趁着自己记忆不太模糊,好好的回顾一下还是蛮有意思的对吧。
Part-1 后验之明
三次作业从结果来看,看起来写的还可以?没被别人挑几个错,倒是也没挑别人几个。第一次1:1,作业被人挑出了一个输出的ERROR,挑了别人一个Crash;第二次0:0;第三次3:0;好像看起来写的都没啥问题对吧?
但是毕竟人们去做反思的时候都是已经知道了结果的时候,所以这个时候的思考很难做到客观,或者说很难还原当时的场景与心态。就好像考试得了100分之后,就忘记了考场上有多么犹豫不决似的。
每个人的程序在真正跑出结果之前,很少有人能够百分百保证自己的代码完全没有问题,所以真正的DeadLine之前,重复的检查自己的程序就变成了人之常情,但是这样真的好嘛?人不是所有时候都能保持一颗平常心的,越是到最后,发现自己有错,就越慌乱,可能越改越错。其实可能只是某个大括号没有对齐?或者是样例输入错了?对自己的算法自信一点,才是我们真正应该训练的不是嘛。
当然,这就需要我们在真正动手之前全盘的规划了,所以说,其实OO的核心就是仔细阅读指导书,尽可能和同学们多讨论讨论边界情况,然后理理思路看看哪里有难点,不要害怕自己的独到方法被别人学了去,让更多的人帮你检验你的算法,更能帮助你理清思路呀。
所以最好还是不要唯结果论,因为全部正确也不代表没有错误,更不能代表代码简洁思路清晰,毕竟怎么走过来的只有自己知道,所以适当的反思是必须的,而且还要装作自己不知道结果的反思,和高中英语似的,有了标答谁都能站起来“合理”分析一通,没有标答能肯定自己的程序没有BUG的才是高手呢对吧。
Part-2 还原场景
现在就先回忆一下当时拿到指导书到提交截止前的经历吧。
一、第一次面向过程的JAVA
最开始拿到指导书的时候,感觉这道题好简单呀,原来数据结构不是写过类似的题嘛?感觉根本不用费啥劲,果然第一次作业就是让大家练练手。正巧那一周忙忙冯如杯,于是周二晚上才开始真正动手,也预示着这会是三次作业以来唯一一次熬夜。第一次作业就写到三点???什么鬼???
可想而知第一次作业写的并不是很用心,脑子里唯一想的就是能不出BUG就行,根本不在意是不是写的精细。由于时间紧迫,也来不及学习正则,好在之前了解点JAVA,写一个面向过程还算顺利。所以第一次作业的就是一个完完全全的面向过程,不会正则表达式,因为既要写C,又要写JAVA,所以就选择状态机好了。在纸上画好所有的状态,就开始动手写C了,顺利写完之后,开始跑几个代码,才发现由于没有好好阅读指导书,连要支持系数指数的正负号都没考虑到,心想,反正是C程序,不用考虑结果的完全正确,改都懒的改了,一会儿一口气把JAVA写完就可以睡觉啦!
于是确实很快就把程序写完了,跑起来也还可以,该实现的都实现了,不过就是只有一个类,丝毫没有体现出对象的优越性,但毕竟心想能正确跑出结果就足够啦。第二天抽时间把Readme写完,就自信的交了上去。所以说,虽然没有什么问题,但是写的好不好只有自己心里知道。
那一周的OO实验上,第一次不得不用正则表达式,也是被迫速成,才体会到了正则的极度便捷。
第一次作业,最能让人收获点东西,因为这奠定了后面的OO之旅呀。
1.早点准备,不一定要动手,但是一定要想好怎么写。就好像写C的时候,磕磕绊绊,好多情况没想到;但是写JAVA的时候非常顺手,就是因为清晰了所有的指导书要求,而且程序的各个部分了然于心。
2.感觉作业都不会太难,不像算法,应该不存在一点头绪都没有的情况,但是麻烦是必然的,所以如何防止缝缝补补才是关键。
3.关于面向对象,这一次匆忙,没有关于技术方面的认知,之后才体会出一些Debug方法。
二、一个看起来不错的傻瓜电梯
曾为年少无知不谙深浅,但少年总会成长的。根据第一次的所得开始第二次作业,提前准备。早早地把指导书读了几遍,大概有了些想法,之后又间断的想了多次,找到了一个认知范围内感觉最方便的方法,周日晚上完成了输入部分,周一11小时的课没时间,周二上午一小会搞定了控制部分就完成了,而且没有什么错误,一下子就能跑起来。
第一次尝到了提前构思的甜头,也是因为这一次作业比较简单,所以各个类之间的关系相对来说很明确,但是分工并不太均匀,结构过于扁平化,出现一对多的情况。这一次没有继承和接口,所以类图看起来单一一些。
- Begin类:属性为电梯、楼层、控制器、请求列表,方法为信息输入,main函数用于程序的执行,负责创建Controller\Elevator\Floor\RequestList四个类。
- Controller类:属性为现在请求、现在时间、之前时间等,方法为执行下一个请求、控制电梯并输出结果、忽略同质请求,负责协同Elevator和RequestList。
- Elevator类:属性为现在所在楼层,方法为生成请求、移动、显示当前楼层,生成Request加入RequestList中。
- Floor类:方法为生成请求,生成Request加入RequestList中。
- Request类:属性为标志、目的地、方向和请求时间,方法为返回标志、目的地、方向、时间,主要负责存放数据,被他人生成。
- RequestList类:属性为存放请求的动态数组,方法为添加请求、返回请求、移除请求和是否为空,被Elevator和Floor进行增操作,被Controller进行减操作。
- Element类:用于存放常量。
三、半智能的意思不就是半智障嘛
从这一次作业开始慢慢体会到了OO 的本质。
怎么能有这么奇奇怪怪的要求???这一次从周日开始看指导书,光是读懂就花了我一天的时间,主要是下午觉得有很多诡异又矛盾的地方,直到晚上新版指导书发布所有地方才清晰。周一一天的课也没动手,相当于构思了两天才开始写。想了两种方法,第一种就是和上一次作业相似,从List中找到下一个执行的请求,然后执行,如此往复;第二种是新建另一个List,找到一条主指令,然后把他的捎带都找出来放到新的List中,然后不停的排序,往复。当时一直在两种方法中纠结,因为每当选定一种方法之后,进一步思考,总能找到一个更不好解决的问题。但也幸亏如此,才让我把两种方法都通顺的思考了一遍,最终还是选择了和上一次有一定顺承关系的前一种方法。
于是周二下午开始动手,一直写了大半天,终于搞定了。可喜的是这样长时间的构思下来,几乎所有地方都考虑到了,而且由于一开始就有一定的全局准备,即使是巨型方法也有很清晰的层次感,虽然更好的方式应该是把它拆成多个小方法,但是修改起来也有了很好的便捷性,知道自己需要改哪里,只需要改哪里。
最难的地方,应该是学会如何合理地继承。由于写第二次作业的时候没有做继承打算,所以对于方法的继承还是很困难的一件事情,因为控制器的集成度太高了,几乎所有方法都是为特定情境而编写的,除了数据结构和同质检测,其他的都要重载,甚至连用都不再用。这就需要弱化方法的功能,尽量减轻单一方法的代码量,避免巨型方法的出现。
- Begin类:属性为电梯、楼层、控制器、请求列表,方法为信息输入,main函数用于程序的执行,负责创建Controller\Elevator\Floor\RequestList四个类。
- Controller类:属性为现在请求、现在时间、之前时间等,方法基本全被Override。
- Elevator类:属性为现在所在楼层,方法为生成请求、移动、显示当前楼层,生成Request加入RequestList中。
- Floor类:方法为生成请求,生成Request加入RequestList中。
- Request类:属性为标志、目的地、方向和请求时间,方法为返回标志、目的地、方向、时间,主要负责存放数据,被他人生成。
- RequestList类:属性为存放请求的动态数组,方法为添加请求、返回请求、移除请求和是否为空,被Elevator和Floor进行增操作,被Controller进行减操作。
- Scheduler类:继承Controller类,使用其属性,重载方法。属性为主请求,捎带请求,计数器等,方法为选下一个捎带请求、下一个主请求、判断同质请求、执行请求、改变电梯方向、删除请求等,负责协同Elevator和RequestList。
- Elevator_method接口:规定了Elevator类应该具有的方法。
- Element类:用于存放常量。
Part-2.5 对于找Bug
当然是先找某些边界情况,保证单一的功能能够全部实现,这就意味着公测没有问题;之后就是各种简单的组合,十几行左右的测试数据;最后再上大量随机组合的数据,如果发现有错误再一点点细化,找到第一个错误出现的位置,然后逐渐简化输入。于别人于自己都是一样的方法。
一开始还愿意一点点读别人的代码屡思路,但是感觉随着任务量的增加,以后应该会以测试为主,阅读为辅,定位别人的错误,以构造出最简单的输入样例为目标。分配第三次作业的时候,通过100行的输入发现别人有错误,最后一点点化简为用4行输入就报错,这时候错误类型就一目了然了。
Part-3 结语
从下一次多线程开始,就要开始变难了,希望每个人能根据自己的情况总结出适合自己的心得体会。
上面写了一大堆有的没的,其实一扫而过就可以,因为最重要的在我看来其实就是Timing,不是时间的长段,而是时机的把握,节奏的掌控,写OO就是如此。可是每个人都不一样,所以找到自己的Timing最重要,究竟自己适合什么时候开始动手自己去发掘吧。
虽然没有最开始想的那么系统,但是也还算可以吧!就这样,结束啦!祝大家都能在OO的摧残下心态平和的顺利走下去吧!
所以,看了眼表,连周三的白天都搭进去了???