oo修仙之路

Posted LemonJ

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了oo修仙之路相关的知识,希望对你有一定的参考价值。

 写在前面:

之前听说过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。

以上是关于oo修仙之路的主要内容,如果未能解决你的问题,请参考以下文章

数据库修仙之路

程序猿修仙之路--算法之插入排序

《带你装B,带你飞》pytest修仙之路5 - yield操作

程序猿修仙之路--数据结构之设计高性能访客记录系统

程序员修仙之路- CXO让我做一个计算器!!

程序员的修仙之路——设计模式六大基本原则