oo总结性博客作业

(1)总结本单元两次作业的架构设计  

1.1 第一次作业

1.2 第二次作业

(2)总结自己在四个单元中架构设计及OO方法理解的演进  

2.1 第一单元

   第一单元是正式接触面向对象课程,且在这学期之前我自己也并没有学习过java语言,一开始连正则表达式都无法正确掌握,可以说是很艰难的开端了。

  第一单元的三次作业主要是利用正则表达式判断输入表达式格式是否正确,再对表达式求导,将求导结果组合成项进而组合成表达式的过程,每次作业都会提高要求,表达式相较上一次更难。

(1)第一次作业

第一次的作业中,有三个类:主类(main),多项式(Polynomial),多项式中的项(Term),读入和格式判定的主要是正则表达式。

(2) 第二次作业

第二次作业基本进行了重构,有10个类:

Main:主类。

Gather(所有因数的父类)

Poly:多项式的项,即一整个乘积项。

PolyNomial:多项式,用于求导结束储存与转换成字符串的输出。

Term:多项式中的因数及其指数。

Read:其中包含读入的方法,第二次作业中依然使用了正则表达式判断读入的格式与方法。

(3)第三次作业

第三次作业在第二次作业的基础上稍作改动,改动最大的地方是读入部分,增加了一个类放求导的函数。

Main:主类。

Gather(所有因数的父类)

Poly:多项式的项,即一整个乘积项。

PolyNomial:多项式,用于求导结束储存与转换成字符串的输出。

Term:多项式中的因数及其指数。

Reader:其中包含读入的方法,第三次作业中使用了递归降幂的方式读入。

Derivation:求导。

2.2 第二单元

  第二单元是上这门课之前“大名鼎鼎”的电梯作业,这个单元提出了多线程的概念,在之前我并没有接触过多线程,而在第二单元的作业中,要处理好线程之间的互斥问题,而且调试有一定的困难。

(1)第一次电梯作业(多线程、单电梯、非捎带):

在第一次作业中我一共设置了四个类:

·Homework5类包含主函数,负责实例化进程,并读入请求队列:

·Person类代表每一个人,包含起始楼层与到达楼层和人的id;

·People类存储请求队列,Person的队列,还有一个标志请求结束的标志end;

·Elevator类为电梯,不断从请求队列中读出请求,并执行。在这次作业中,我采用傻瓜调度的方式,并且没有考虑性能,每次只送一个人。

(2)第二次电梯作业(多线程、单电梯、捎带):

·Homework6类包含主函数,负责实例化进程,并读入请求队列:

·Person类代表每一个人,包含起始楼层与到达楼层和人的id;

·People类存储请求队列,Person的队列,还有一个标志请求结束的标志end,比较第一次作业加入了现在在电梯上的人的队列;

·Dispatcher类存为调度器,其中包含判断运行方向的函数,达到捎带的目的,以及上电梯下电梯上人下人的函数。

·Elevator类为电梯,改变了第一次的轮询写法,主要以楼层作为循环条件,进行电梯的调度。

(3)第三次电梯作业(多线程、多电梯、捎带):

·Homework7类包含主函数,负责实例化进程,并读入请求队列:

·Person类代表每一个人,包含起始楼层与到达楼层和人的id;

·People类存储请求队列,Person的队列,还有一个标志请求结束的标志end,比较第一次作业加入了现在在电梯上的人的队列;

·Dispatcher类存为调度器,其中包含判断运行方向的函数,达到捎带的目的,以及上电梯下电梯上人下人的函数。

·Disspatcher类为本单元新增的类,主要是为换乘的功能添加。

·Elevator类为电梯队列。相比较于前两次作业增加了两个电梯。

2.3第三单元

  第三个单元是学习JML,这个单元有官方开源接口,我们需要做的就是对于接口的实现,不太涉及到结构的设计,重要的是理解接口所描述的JML语法,这个单元考察的不是自己的架构设计,而是对于一个任务接口的实现,当有了基础的结构,思考怎么样才能更好的完成。

(1)第一次作业

  第一次作业中,要求实现一个PathContainer类,该类可以对Path类对象进行存储和处理,这部分作业实际上没有涉及到算法的选择而且很简单,根据规格写出代码即可,我创建了一个Arraylist存储Path对象的ID,存储Path对象自身时,也使用了 Arraylist 存储,由于此次的作业有复杂度的要求,所以我选择了将查找的复杂度“分配”给了插入和删除的方式。

(2)第二次作业

  这次作业在第九次作业的基础之上进一步实现一个Graph类的图,并通过该图找到最短路径以及两个节点之间的连通性。我依旧使用了Arrraylist实现了图,并且通过每次插入删除时更新灵界矩阵的方法,运用弗洛伊德算法(时间复杂度是o(n^3)),玩完成了此次作业。

(3)第三次作业

  此次作业要在上一次作业的基础之上实现一个RailwaySystem类的图,有三个要求:

(1)查找最短路径:(2)不满意度最低:(3)花费最少。这次我的算法的选择是在年级群里大家给出的算法建议,但是我也一直无法整明这个算法的正确性,又找不到反例,虽说是通过了强测和互测,我还是有一点疑问,需要更进一步的学习。

2.4第四单元

  第四单元是学习UML,这个单元我们不仅要去学习官方开源接口的实现细节,还要去掌握UML图的画法和内容,类图、顺序图和状态图是这个单元的三大处理图。

(3)总结自己在四个单元中测试理解与实践的演进

3.1 第一单元

  在第一单元的三次作业中,刚开始学习java也遇到了许多困难,第一次作业中第一次利用面向对象的思想编程,进行简单的求导,完成的不算很差;

  在第二次作业中,提高了一些难度,我很不幸的翻车了,写错了在正则表达式,而且因为对自己架构的不熟练,导致出现了很蠢的bug,做作业的时候也花费了很多的时间,而且强测的成绩也很不理想,体会到了思路清晰的重要性;

  在第二次bug修复中改正并做修改完成第三次作业,第三次作业相对于第二次作业变化并不算大,因为第二次的代码结构还不错,所以第三次没有花费过多的精力,也让我体会到了代码扩展性的重要性。但优化很难,由于担心正确性,并没有做优化,这也是较为遗憾的一点

3.2 第二单元

  第二单元相较于第一单元难了一些,主要难度在线程安全和设计原则的问题上。但由于第一单元打下了基础,在语法和代码上已经不是问题了,主要的还是线程安全的问题。但在这一单元的第三次作业中还是出现了一些问题,好在bug修复环节改正了。

  在这一单元中主要考察的就是对多线程的理解,但如果没有第一单元的基础,第二单元也很难完成。

3.3 第三单元

  这一单元与前两个单元比较算是十分简单,看规格,翻译成自然语言,看不懂规格就去看指导书,然后写出代码,整个过程比前两个单元轻松了不少,通过对JML的学习,我也体会到了好的架构设计对编程的重要性,自己编写JML也并不是一件容易的事情,是需要大量锻炼的。而且我体会到了通过JML对设计架构与代码维护的好处

3.4 第四单元

  这一单元我的感受是“比较麻烦”,"但不困难",首先是对于UML的理解与使用,还有就是对代码的编写了,经过前三个单元的练习,代码编写难度并不高,但是难的就是对UML的理解了。

(4)总结自己的课程收获

  一学期的面向对象课程正式结束了,我也有很多收获。

  首先,当然是掌握了java这门语言,我在这之前并没有接触过java语言,这个课程通过每个单元的大作业让我深刻的学习到了java编程。大量的作业和代码让我从一开始的连正则表达式都不会写,到今天这个程度。也使我最终对面向对象的编程有了更深的体会。

  其次就是对多线程的学习了,这部分好像跟os课程也可以联系到一起,但我自己感觉并没有完全理解线程安全的处理和保证,以后还得多加习。学习多线程真的很有好处,设计的困难,理解的难点和错误的不可复现性,或者一系列“玄学”问题,都比不过多线程的优势,以大大提升程序的效率,更好的利用机能。

  最后,对于JML和UML的学习,帮助我们提高严谨性,加深层次化设计,让我们对设计架构有更好的把握,可以说是锦上添花。

  这门课确实给了我很多压力,几乎每周都要完成作业,而且作业的难度也较大,一开始的时候基本都不知道从哪下手,就算写完还要承受bug改不出来的煎熬心情,而且大量的作业甚至几乎治好了我的拖延症。但与此同时,我的编程能力也提升了,从一开始写代码,写的乱七八糟毫无架构可言,到现在也能勉强写出能让人看懂的代码了,这一门课学下来,确实是这学期很累,但也受到了很多锻炼,对编程能力的提高,对思维方式的提高,一步一步学习编程,还有对代码测试的理解,以前写代码完全没有这方面的觉悟,在互测环节中,还可以阅读其他同学的代码,通过交流学习,体会到了交流学习的魅力。面向对象不仅仅是一门必须要上的专业课,更重要的是让我体会到了效率,与思想方式的重要性。

  回想这一学期,确实挺累的,有oo和os两座大山,还有离散等课程,但对于oo的学习一直放在首位,虽然仍然有很多的遗憾,但更多的是感激与收获。因为oo,每周都过得十分充实,从作业发布开始,就不敢松一口气,理解题目,整理思路,设计架构,代码完成,debug,还要进行互测,在完成作业的过程中,还能体会到客服困难时的欣喜,解决问题的开心,好像就是“痛并快乐着”,这是一种非常难忘的体验,相信这也是我大学课程中最难忘的课程之一。

(5)立足于自己的体会给课程提三个具体改进建议

1. 在第一单元的学习中,我觉得对于初学者还是比较困难,也有点打击自信心,所以希望第一单元的难度是否可以适度降低些呢。

2.互测的过程中,一开始第一单元,情绪比较高涨,但是越到后面,看别人代码的兴趣就没有了,也不想找别人的bug,一组的人数是否有些多,这样其实也并不太利于互测,减少一组的人数似乎是个好办法。

3.个人感觉强测扣分比较狠,同一个错误可能会扣掉几十分……

感谢每一位老师和助教的辛苦付出!!!

猜你喜欢

转载自www.cnblogs.com/chengfangqi/p/11074677.html