oo修仙之路

Posted 2020-10-29 LemonJ

 写在前面：

之前听说过oo这门课的威力，计院全体修仙现场的图也被转了不知多少遍，然而自己不亲身经历就不知这门课的难度所在。每次debug时耳边总会想起三国杀里面周瑜的话“挣扎吧，在血和暗的深渊里；痛苦吧，在仇与恨的深渊中！”oo对我来说大抵就是这样，痛苦却无法避免，下面就来回顾一下这一个月以来的oo生涯。

第一次作业：

第一次作业我美滋滋地以为老师会讲Java，像c语言和数据结构那门课一样，第一次作业并不会太难。然而我太天真了，第一次作业就给了我致命一击，看着如同天书一般的指导书，生平第一次懵了。正则表达式是什么？老师连Java基本语法都不教的吗？（老师：没错儿~）马克思说过：当你不会写代码的时候，你就去多看看别人的代码，学习学习就会了。（马克思：我没说过）于是秉承着这一理念，我去问学长要他的代码看看，试图从中分析出一些东西。然而，不会基础语法的代码就像一盘散沙，不用run它自己就散了，我并没有分析出任何东西并且写出了一滩狗屎。这个时候我才想起来，应该去好好听听基础语法课，看看基础语法的书。这是我第一个致命错误。

第二个错误就是我没有一个良好的规划，这也是我在三次作业中犯的共同错误。因为这个原因，我常常搞不清我现在在干什么，下一步要怎么做，也导致了写代码时本来应该先完成基本功能再去往里面加东西，我却是写着写着就加进去了，导致后面工作无法展开，一塌糊涂。

第一次作业是处理多项式加减运算的模拟计算器，说到底我写的还是一个面向过程的代码。在读取时，采用了逐字符读取的方法，由于正则表达式没能学好，最终还是选择了状态机。而由于状态机的问题，对于正常输入也总是报错，导致了代码正常功能测试没有通过，成为了无效作业。之后在课下想通原因进行了调整，重新用正则表达式写了（在这里我要感谢实验课，不知道为什么有些东西在课下怎么都想不通，一旦上了实验课，在ddl的夺命连环call之下，一下子就想通很多问题！真的太神奇了！小岳岳脸.jpg）。但第一次挑战依旧是gg了。在这里就不放第一次作业的类图了。（就一个类而已！请你闭嘴好好反思行吗！）

胜负乃兵家常事，大侠请重新来过！

第二次作业：

第二次作业gg的理由非常简单，我作死地让命令行输入要进行的电梯操作，让控制台输入“run”，这样公测当然通不过啊！！！公测怎么有那么智能？！这个gg的理由被我们宿舍笑了好久，我也想乘坐时光机回去问问我自己到底是怎么想的啊……

放上修改以后的类图（我以后再也不想碰命令行了……）：

 

 

这次作业写起来还是很困难（这不是废话吗……第一次作业就那么艰难），主要原因是我不明白为什么需要五个类，这五个类到底要干什么，他们之间的关系是什么。在询问过某位大神之后，终于对于面向对象有一点点理解了，也明白在面对一个项目时，要怎么去分析和设计。

本次作业要构建一部傻瓜电梯，使用五个类完成，Elavator类共有5个属性，3个方法，分别实现返回时间，楼层，计算上下楼层所需时间并更新当前楼层的功能。

Floor 类十分鸡肋，没有程序应用上的作用。

Request类有4个属性，6个方法，分别实现返回目标楼层，时间，请求类型 ，电梯运动方向，对这些变量的赋值和计算赋值。

Requestqueue类中有1个属性，6个方法，方法规模都很小，只负责返回请求，计数及将新的请求加入到队列。

Dispatcher类类中有2个方法，其中一个用于建立队列处理输入，另一个用于返回队列。

第三次作业

第三次作业说起来轻巧，是在第二次作业的基础上增加“捎带”功能，然而真正写起来复杂程度超出了我的想象。过分细化的定义让人一头雾水，而这也是第一次有效作业emmm……应该说还是挺开心的，看到作业有效后狠狠哭了一场，有一种修仙小说中凡人刚刚达到炼气期踏上仙途第一步的感觉。

话不多说放上类图：

 

 

我的bug：

这次作业公测挂了三个点，第二次作业对于同质请求没有写好，导致了第三次作业挂在同质点上了。自己在给别人测的时候发现了一些我程序上边界点的bug，

但是给我测的那位同学没有发现orz没有被报bug虽然挺开心的，但是并不能说明程序就真的没有bug了，还是要努力改正。

别人的bug及测试方法：

在宿舍同学的指点下，我发现可以根据测试树先全面地写一份测试用例，互测时全部跑一遍。

通过这个方法找出对方非常多bug，比如说时间限制、乱序处理、捎带不捎带、同质不同质……

阅读对方readme中的各种规定，有时从他的叙述中可以发现逻辑上的错误，进而构建测试样例（那岂不是美滋滋，而且第三次作业但凡涉及捎带问题，up和down对偶性构建测试样例，一查一个准）。

这个就有点困难了，而且有种语文作业咬文嚼字的感觉，在身边同学几次撕逼的过程中也发现，基本通过这种方法找到的bug就和甲方乙方互相不理解一样，各说各有理，我个人不是很喜欢这样测试。

不过为了避免被别人通过这种方式构建，还是要好好写自己的readme！

最后就是仔细阅读别人的代码，发现其代码中的不足从而测试

对于目前的我来说，这几乎是不可能的。我ball ball各位大佬们下次能不能给自己代码写上注释，写注释看起来都很困难，不写注释是真的要很久才能看懂（所以我放弃了）

一些心得体会：

1. 不抛弃，不放弃。第二次作业无效的时候已经考虑退学了，最后被现实一个巴掌扇了回来（拿不到大学毕业证书真的太难生存了）。哭着跟父母说我不上了，反正也学不会，最后想着能学一点是一点，硬着头皮去看书敲代码，边哭边敲，居然也熬过去了。当然在这期间少不了很多人的帮助，想想之间钻牛角尖走不出来的日子只觉得可笑，逃避解决不了任何问题，只能让自己变得越来越差。不要把oo当成洪水猛兽，当成修仙好了（23333），刚刚踏入仙途，还没筑基，会面对很多困难。修仙路上是有天才，资质较好，年少便已名扬四海，像我这种呢，就是个外门小弟子，能力不强，心魔还挺重，但是为着未来或许有的一点希望，还是要努力地去拼搏啊。
2. 认真对待每一次作业，要有清晰的思路分析，而不是像我一开始一样东一榔头西一棒子。鲁迅说过，只有经过设计的程序才是好程序。（鲁迅：我没说过）为什么一直浪费时间却做不出来，很大一部分源于没有认真设计该如何构造，才导致后期越来越模糊越来越不知道怎么写。
3. Bug一定要改，虽然我嘴上说着“除了crash问题其他bug我绝对不改了”，但是身体还是很诚实地去改bug了为什么啊！因为后面的程序是在这个程度上叠加的，如果现在的bug不改，之后可能会出现大问题。
4. 互帮互助、团结协作。这是oo让我意识到的非常重要的一点。没有人是一座孤岛，一个人的bug可能是一群人的bug，同样，一个人的数据也可以是一群人的数据。这门课不是养蛊，一个个斗个头破血流你死我活才算胜利。诚然，互测中有恶意扣分的现象，也绝对无法达到乌托邦的理想世界，但是我还是想说，这门课重要的不是你给别人扣多少，而是你能不被别人扣多少。
5. 锻炼身体，好好修仙。熬夜到喝速效救心丸的经历我不想有第二次。

 

言尽于此，兴致阑珊，还是那句话，愿天堂没有oo。