OO第四次博客做业（第四单元做业及期末总结）

（注意：本文写做顺序与做业要求不彻底一致，但涵盖了做业的全部要求）

　　一学期的BUAA特点OO课程结束了。

PART 1  我想先写我这一学期的感想

　　从第一单元满怀期待地写完多项式求值到最后看着60分不到的成绩伤心欲绝（这个词用的其实并非特别夸张），到第二单元做业在截止前两小时还在作不停地思考和调试，再到第三单元在活页纸上记下一种又一种可能的实现方法（而后还有一堆bug2333），最后到第四单元，也就是这个单元的与考期共舞，与程序广度做斗争，每一个单元都是你从未玩过的船新版本（由于OO课程改革因此还真的是船新版本），每一次做业都带来彻底不一样的体验。虽然写做业的期间，不只是我，好多人面对满屏的代码和各类各样毫无逻辑的bug陷入自闭，但一旦挺过来，回头一想，本身确实完成了一些规模比较大，架构较为复杂的项目，并且是在比较短的时间限制内完成的，虽然仍是不能从根本上改变咸鱼本鱼的本质，但至少算是作了比较大的努力，实现了一些之前本身不敢想的事情吧。从一学期的OO课程一步步走过来，回过头发现，本身真的走过了一段很远的路了。

PART 2  写完感想再写一写对OO课的祝愿，感受这样行文比较流畅

　　以前的博客做业没少发过牢骚了，这一次，做为课程的结束，想发自心里祝愿这门课在之后能愈来愈好，能为学弟学妹们提供更好的指导做用。虽然，按当今的社会情况，不要说一门课，经过整个大学阶段的学习，也很难从本质上改变乃至塑造一个成功的人，就比如只能对一棵已经长成的树作一些修修剪剪，而不能从一棵小树变成一棵参天大树。可是，我仍是但愿，哪怕只是想象一下，让学了这门课的学生，至少有一个自信，他可以胜任一些中小型的企业工程项目（更激进一点的想法，应该是大中型），有能力去企业作一些相关的实习，更好地与将来的工做相接轨，而不要让他们感受本身不管学没学，都仍是一条不中用的咸鱼。

　　若是说具体作法，首先既然谈到实习，那若是有可能的话，能够真的为学生提供哪怕只是一周，或者一个中型Project的实习机会，去与工业界最亲密地接轨。可能对于至关一部分人（也包括我），仍是须要以相似于做业的形式进行逼迫（或者说被动）式的学习才能真的吸取一些东西，既然这样，那把他们置身于工业界，置身于职场，在那种紧张的环境下，多是对他们更加直接的逼迫，让他们感觉到从构思到测试以致release的每一环节的不可或缺，全过程地感觉“钢铁是如何炼成的”，这里的钢铁固然是代码的“钢筋铁骨”。限于条件，也能够进行相似于工业环境的模拟，但总归是差了点感受，尤为是在测试的迫切性上。感受只有置身于工业级的程序发布环节以前，才有那种必须不断、反复进行测试的必要性和紧迫性，才会真的想去一遍又一遍地进行各类测试。

　　另外，若是局限于做业的形式，我以为咱们写的程序虽然在难度上真的不低，但距离一个真正由现实用户使用的程序，还差了一个难度上不大，但对绝大多数程序都不可或缺的环节——图形用户界面GUI。虽然通常的程序设计课上，不太可能单独掏出一个板块来说解GUI的设计，但咱们BUAA的OO原本就不是通常的程序设计课，它是基于project来实践练习的课程，既然如此，何不让课程内容覆盖更加完整，来一学期”从内到外“的面向对象编程练习呢？我的甚至脑补了一个具体的实现方式：在project总数不变的状况下，把JML第1、二次做业合并，挤出一个作GUI做业的project（我的感受，在工业上与学术界普遍使用的UML，比实际用的很少的JML反而少一个project，自己就不怎么合理，感受UML是一张真正的蓝图，而JML更像是一种玩具），在最后一次做业中完成一个GUI的设计。测试时若是没法实现机评，就用人工检测的方法，检测程序是否可以经过图形界面操做，实现对应的功能。这样一来整个project的难度其实会相对简单一些，必定程度上减少了烤漆复习的压力。还能够采用比较特别的性能分区分方式{好比按UI美观程度给分，固然不要太过度，只要不是BAD UI就拉满），给以前单元学到快自闭的咸鱼们一个翻身的机会，毕竟做为一门课程，给予学生充分的自信心是必要的，总不能让人一直coding司马脸，debugging司马脸吧。

　　上面的建议可能太过空想化，仅仅做为我我的的一点祝愿写在这里吧。另一些细枝末节的建议，就是尽可能让每次指导书的要求明确一些，不要有bug或者含混不清的地方吧。固然这个事情是不能强求的，我本身写的程序都有一堆bug，又有什么资格苛求别人呢。

　　（以上三段在统计时每段算作一个建议吧，太长看不过来的话）

PART 3  回归本单元做业

　　两次做业放在一块儿讲吧，懒得分段了，况且它们是包含而不是并列关系。

　　这单元的做业，从难度上可能不是特别大，但广度上真可谓无可匹敌。先是关于UML类图的各类操做，后又扩展到顺序图和状态图，还要实现对类图的基本规则验证。这就直接致使了一个结果：最后一次做业的代码量远超以前任何一次做业，成为爆肝的有力见证。

　　一开始我想直接采起遍历输入的方式实现每一个功能的操做，结果证实行不通（这不是必然的吗？）。以后便老老实实地按UML结构创建了保存类模型的struct，从class，到attribute、operation，再到parameter，一级一级创建起来一个完整的结构，也就意味着说初始化的时候要遍历至少三次输入。类和接口采用同一个结构模型，只用了一个boolean变量来区分两者。对于继承、实现、关联等各类各样的关系，采用两头区分的方法，以继承为例，有一个保存父类的ArrayLIst AppendFromList，也有一个保存子类的ArrayLIst AppendByLIst，这样就将全部的输入信息转化为便于处理的，相似于图的结构了。对于UML顺序图和UML状态图，我也采用了相似的处理方式。实际上，此次做业中至关的码量和时间，耗费在告终构的构造和构造方法的书写上。

既然这单元学的是UML，那我就导出一个超级大的UML类图放在这里吧（手动滑稽）

　　代码的核心逻辑部分，我以为本身真的是吃了数据结构，尤为是图的部分没学好的亏，老是出问题，出各类问题，害得我半夜3点又烧脑又爆肝地debug。就算我投入了大量精力思考致使bug的缘由，就算最后一次做业要求已经简化，强测的bug最后仍是出在了图结构上。第一次的bug没什么好说的，没完成指导书要求（还真不是没看，解决方法都想出来了，感受本身明明写了，结果发现没有，晚了！）加上迷信指导书样例，忽略了接口重名要重复输出这一点。第二次的bug，checkForRule008改了好几回仍是挂了一个点，暂时先无论了，专心把博客写完，你看又半夜12点了。

PART4 总结四个单元架构设计和OO方法理解的演进

　　由于寒假预习工做作的不错，至少在理论层面，对OO方法已经有了必定的理解。

　　第一单元：理解归理解，在至关多的地方，面向对象的方法没怎么体现出来，无非是将表达式拆成了三个部分。但就是这门一分，带来了面向对象给我带来的第一份便利：化整为零，用简单、细小的部分拼凑成复杂的、庞大的部分，用简单、短小的方法去实现复杂、冗长的方法。虽然构造方法上，结构式编程的痕迹还很是明显，但封装、继承、接口实现等基本操做已经获得实现（P.S. 如今想起来第一单元做业还重复继承过接口2333），到第三次做业，已经不可能再用结构式的思惟去实现，而凭借前两次做业的面向对象基础，就比较轻松地完成了。

　　第二单元：与其说面向对象，不如说这一单元演练的是多线程编程的能力。可能在写的时候，并不以为由于面向对象带来了多大的便利，不事后来证实那是由于多线程编程自己的难度，而不是面向对象方法不行（写完OS Lab4的fork函数就知道了）。这单元是最难的一个单元（虽然就这么一句话让我每次都有后面单元很简单的错觉，而后每次都写到自闭），最后一次做业更是难上加难，电梯的封装、调度器的实现、调度算法的选择、多个电梯线程与调度线程和输入线程的同步，随便一个均可以难倒一大片人。尽管最后没有可贵地没bug实现了，但面向对象的程度还不够，代码耦合性比较高。

　　第三单元：此次绝对是正宗的面向对象编程了，惋惜封装的部分不是咱们亲自完成，而是助教帮咱们实现的。架构上也并不困难，就是典型的无向带权图，加上严格的卡时间限制，仿佛穿越回了一年前的数据结构课堂。但与以前不一样的是，此次是采用面向对象方法实现的图结构，用更少的码量、更清晰的程序逻辑，实现了更为复杂的功能。

　　第四单元：和上次相似，也是助教帮助咱们进行的封装，并且此次帮得能够说更多，以致于架构占了码量的大头。并且架构实际上也有种还原UML图的意味，虽然工程量大，但难度上并不过高，甚至给了我一种再加把劲能够本身写出来个StarUML的错觉（被打醒）。

PART5 总结本身在四个单元中测试理解与实践的演进

　　简直是哪壶不开提哪壶，丢人啊。看那个翻车的表情包我真是想笑又笑不出来。

　　第一单元测来测去，覆盖性不足，扑街；第二单元，借助别人写的测试工具，好歹是测出了几个重要的bug；第三单元，感受上没问题了，但感受这个东西真的一点都不靠谱，想作一些测试，JML跑不了，想写JUnit，发现本身不会用，根本上仍是测试不充分的问题；最后一个单元，迷信指导书样例，忽略重要状况。

　　由此就能够看出一个要命的问题：覆盖测试。这里指的不是代码的覆盖，而是各类状况的覆盖，说白了就是多跑几组不一样的样例。覆盖测试充分的程序，bug就少或者没有；没怎么进行充分测试的程序，bug就多得使人发指。基本的功能测试和单纯的边界测试并不困难，但想要作到覆盖测试却很难，最难的一点，就是很难经过人力来进行覆盖，测来测去总漏边界状况。关键是对于一个有bug的程序，它引起bug的边界是不肯定的，这是我写代码的时候最最最最头疼的一点。