302
社区成员




#第四单元总结
在第一次作业中,我们要求实现一个简易的图书管理系统,这次作业相对于前面三个单元来说,绝对难度确实是小了不少,但是毕竟没有往届学长学姐的博客作为参考,刚开始的时候确实有点无从下手;但其实作业已经给我们了答案,就是利用UML进行规划,也就是刚开始的时候就可以根据UML中的类图、状态图、顺序图等规划我们的大致结构。因为这次的作业的整体要求其实非常明了,框架也很清楚,大致可以分成MyLibrary,MyBookShelf,MyReserveOffice
等几个类,而分类的规则也很简单,就是根据各个单元进行分类,以达到实现各自独立功能的作用。
这次作业的实现在框架确立后十分容易,因此不再赘述具体的实现细节,包括后面的简单部分。这里分享一下类图的构建。
我们类图的实现实在StartUML这个软件上布置的,在初学者(主要对于本单元作业),我们需要掌握的其实不算特别多。
左边栏拖入类框,单击右侧分支对应部分,在右下角部分进行信息的修改(注意!画布上的显示部分与实际上不一定一样!在评测时是根据右边的分支进行评判的,所以可能会出现通过左边画布删除之后,右边的分支仍未删除而导致的问题!切记一定要在右边进行更改)
属性介绍(以及本单元要使用的部分)
主要更改的是name,visibility,type
name,visibility
name,type,direction
各种连线的简易判断
在本次类图实现中,主要由四种关系可以使用:关联、依赖、组合、聚合。下面我说一下本人的简易判断是哪种关系的方法,不保证正确但很好用。
关联就看在另一个类中有没有这个类的影子,没有就不用连,有的话接着往下看(就是因为这个所以大部分都不用关联关系)
如果直接引用这个类作为元素,就是组合;如果间接引用,如HashMap<MyStudent,Integer>就是间接引用MySttudent,属于聚合;如果不是在属性中出现,而在下面的过程中实例化了这个类,就是依赖关系。
紧接着,我们就可以根据我们事先画好的UML类图进行实现了,注意在这过程中我们难免会遇到unexpected problem,可能需要额外的函数,这是正常的,但是UML之中定义的函数必须要实现。
在这里还有一个点,就是对于预约请求的处理;前两次作业中,并没有对预约请求的处理提出要求,只说了可以选择适当的策略,建议以提高借阅率为基础,但不允许一味的拒绝。这里一般有两种想法:
至于其他两个图读者可以自己学习一下,相对还是比较简单的。
整体的代码设计都是遵循着我事先画好的类图进行的,在两者的一致性方面是完全吻合的;在这过程中给由于一些事先没有考虑到的因素我也适当的对UML模型进行了一定的修正。
在刚开始接触OO的正课的时候,虽然刚开始的时候已经接受了oopre的培训,但是在写架构的时候还是摸不着头脑,感觉主要是出于对于这么大的架构可能有点畏惧心理。在第一单元的时候,虽然感觉可以用项、表达式等进行划分类,但是出于对失败的害怕,就感觉有点不太敢下笔,最后带来的结果就是在哪里发呆了好久;而且实际上,那时候的设计只是一个模糊的架构,并没有一个准确的类图,但是经过一个学期的磨练,特别是以一个UML收尾,能将架构设计更加的具象化地表达出来,从而加强了架构设计的意识,真正从面向过程编程变成面向对象编程。
从CO到OOOS,测试的重要性也逐渐体现出来。OO的测试尤为重要,否则一不小心在强测中挂掉了的话就会得不偿失。由于有一位大佬搭建了评测机,我就没在自动化测试这里花费多大的功夫,主要搭建的评测是第一单元的递归下降的评测。那时候是我第一次写了一个完整的对拍程序,在之后虽然主要依靠别人的评测机,但还是会自己捏造一些极端的数据进行测试。OO也让我明白了测试的重要,也为之后工作的测试领悟得到了提高。
OO课程作为计算机学院的一门核心课程,其所锻炼的不仅仅是我们写代码的能力,也不仅仅是我们以对象的角度来思考进行面向对象编程的能力,而更是一种将解决问题的思维进行拓展的一种能力,锻炼我们从不同角度进行思考问题。同时,这也是一种磨砺,从各种不同的角度对我们进行锻炼。回首这一个学期的学习,每周对着那每次题目的阅读,每次进行构思,每次从不同的角度解读问题,每次写出bug又找出bug,都是我们对OO课程的美满回忆。轻舟已过万重山,后面的路还很长,希望我们带着OO给我们的宝贵财富继续走下去!