Java第四单元暨面向对象课程总结

 

1、第四单元做业框架

一、UML类图解析器

    （1）设计策略

    做为对UML的入门，此次做业主要考察了咱们对于UML类图的构成要素的解析方法，并经过这种方法加深咱们对于UML的理解。

    对于从UML图中解析出来的信息进行分析与汇总，实现对于UML类图的各类元素（包括类的个数、特定类中所包含的属性个数等）的查询。在作此次做业时，我将各类元素（UMLClass、UMLAttribute等）进行了分门别类的存储，使得元素可以对应所在的类，实现查询功能。

（2）类图

         因为本次做业只是对于UML类图中元素的解析，因此只须要将各类元素分门别类地initial处理一下就可以实现功能，因此我只是用了一个类来解决这个问题（所以只截取了一个类的视图）。以上便是本次做业的大致框架（seekforinterfaces、seekforancestor分别是处理interfaces、class之间的继承，seek、todo分别是这两个方法的递归作法）。

（3）度量分析

 

二、解析器的拓展（顺序图、状态图）以及基本规则的验证

（1）设计策略

    在UML类图解析器的基础上实现对于顺序图和状态图的解析，实际操做流程并无改变，都是经过对于存储各类不一样元素的相关信息实现对应因素的关联，与第一次做业相似。

    而对于基本规则的验证（元素重名、循环继承、重复继承），则是本次做业的难点所在。因为第一次做业须要经过递归实现对于最顶级父类的查询，若是出现循环继承则在查询的过程当中会发生死循环，因此在咱们实现继承的查询时，咱们必须得保证当循环继承发生时，咱们要有方法使之“停下来”。

    在个人设计思路中，我在发现循环继承的类（接口）时将该类的继承寻找工做停下来，并将其最直接的父类从新赋予它（保证其余类在测试是否循环继承时不受影响），并将该类从就绪队列中剔除，保证它不会干扰到其余类的寻找工做。

（2）类图

    与第一次做业相比，第二次做业因为多种图的区别，我加入了不一样的类对于不一样的图进行了信息的初始化工做，代码量较第一次做业有了一个飞越。

（3）度量分析

 

 

 

2、四个单元框架的改进及oo方法理解的演进

（1）框架改进

    在本学期oo课程的学习过程当中，咱们一共经历了求导、电梯调度、JML语言的探索以及UML工具的探索一共四个单元的学习。在学习第一个单元时，我对于框架的理解还不够透彻，程序大多一个到两个类，将各类方法都堆积在构造器中，企图以一个程序做为方法实现的所有内容，最终也形成了个人代码可塑性不好，基本上每次做业都须要重构。

    而在学习二三单元时，我可以根据多种方法的实现结合成一个类，保证了代码的可读性。因为官方接口的提供，个人做业可以逐步“适应”短而精的方法实现，在代码的规范性方面有了很大的提高。但在代码的拓展性方面个人做业仍有所欠缺。例如在电梯调度的过程当中，个人第一次做业（傻瓜电梯）并无使用楼层开关门的逐级判断，而是直接令程序sleep乘客从起点楼层到终点楼层的时间，致使在后面做业中须要对于电梯升降过程的方法实现进行重写，浪费了时间也错失了锻炼实现代码可拓展性的良好机会。

    在第四单元的锻炼中，我可以很清晰地使用第一次做业的类图处理方法对于顺序图和状态图实现处理，代码可拓展性有了较大的提高（固然也有较为类似的因素在其中）。可以经过继承等方式实现类的有序管理，实现了必定程度上的突破。但在命名方面仍有瑕疵，随性的命名方式使得我在读本身的代码时都会遇到不知道方法或是变量是干什么的窘境，这也是我在接下来的代码编写过程当中所须要注意的。

 

（2）oo方法理解的演进

    在学习这门课的最开始，我觉得oo是实现处理某个具体问题的课程。因此在个人潜意识里，可以最准确地实现所须要的功能就是一个好程序。

    因此我在前两次做业中堆积“屎山”代码，只为了可以在一个类中实现所须要的功能。然而对比强测组内其余同窗的代码，我发现我本身彷佛更喜欢读他们的代码？在代码的可读性上，我发现我存在着巨大的问题。

    而后就是第二单元以及第三单元，一个是对于电梯调度时间的限制，一个是对于程序CPU时间的限制，让我明白了程序的性能也是程序好坏的重要评判条件。只追求正确性并不能作出一份好的代码。

       oo（面向对象）让咱们学习了如何去实现一个需求，让咱们知道了封装、继承和多态，也让我在实际写程序的过程当中主义代码的可读性和延展性，养成了良好的写代码习惯。

 

 

 

3、测试理解与实践的改进

    在本学期的面向对象课程中，每次做业的评判有中测和强测之分。中测的样例较为简单，并不能支持咱们必定可以经过强测。因此作好数据的自我测试也是重中之重。

    因此我知道了如何去使用对拍器。经过对拍器中数据的自动生成，我能够不用再像求导的前两次做业同样本身去苦心积虑地编写数据，而直接由计算机实现数据的自我测试。从第一单元的第三次做业开始到第三单元结束，个人代码充分享受到了对拍器的“红利”，也在正确性方面有了必定的保障。

    然而从第四单元开始，UML文件特殊的输出方式也让我很难实现对拍器的生成。因此手绘UML图成为了我在这个单元测试的关键。考虑极端、边界状况是我在画这些图过程当中所最须要注意的地方，也是我在测试过程当中的难点所在。

    经过四个单元的测试以及自我测试，边界、极端状况永远是一个合格程序可否实现优秀的重要决定因素，对拍器在这方面也有必定的短板（很难造出十分极端的数据）。因此在本身测试的过程当中，作好本身对于这些状况的判断，是我在debug过程当中的一大理解与体会。

 

 

 

4、课程收获

    从一个在学期开始对于java（须要学习的语言）、idea（须要使用的工具）近乎一窍不通的状态，到可以熟练使用idea写出千行代码而不多犯错，我在这个学期获得了很大的收获，可是在细数这些收获时，我却又不知道该从什么方面提及。

可能在我看来，最大的收获就是教会了我应该如何去看待本身所写的代码。仅仅实现了所须要的功能是不行的，在这个性能十分重要的时代里，如何简化本身的代码，实现程序的快速运行和所占空间的优化，也是咱们在编写程序过程当中所须要注意的。

    同时，我一贯不太注重的代码风格在这个学期的面向对象课程学习过程当中也获得了很大的优化。因为以前的数据结构、计算机组成等课程更加注重一个程序功能的实现，代码风格历来都不是咱们学习成绩的影响因素，因此我在写代码时也常常会十分随性。可是当面向对象设置了咱们做业的规范要求并设立了多人互相交换检查做业的机制时，我也才意识到本身的代码风格对于别人的理解以及程序后续的开发工做是有多么的重要，也可以在每次做业中都细心检查本身的代码风格，养成这一良好习惯。

    授人以鱼，不如授人以渔。Java语言的学习在我看来反而并非这个课程最大的收获。oo课程的一大优势就是他所教的内容在咱们从此的学习过程当中都有用，而不只仅在java这一个方面。从对拍器的搭建开始（有用python），到研讨课上的分享，本身去尝试新鲜的东西才能保证咱们在计算机领域的不断进步，也能帮助咱们这些菜鸟快速成长。

 

 

 

5、对课程组的建议

（1）上机内容的调整

    本学期的上机前紧后松。从一开始是上午刚讲新知识点，以及下午要求编写实现某个功能（以这些新知识点为基础）的代码，难度太大而且在我看来也没有什么实际的练习意义；到后来有把难度降得太低，只须要认图说话就能作完实验，交一份可以经过编译的程序也成了走形式的一个项目，彷佛也是不太稳当。若是可以将上机内容在早上上课时提早告知，让咱们在听课的同时可以揣摩上机题目，或许可以有更好的效果。

 

（2）做业难度梯度的调整

    在我实际编写代码的过程当中，我认为第四单元第一次做业的难度设置较为不合理。包括继承关系的处理以及对于每一个元素中所包含的信息的归类在是实现上存在较大的难度。相比之下，第二次做业的难度反而都集中在类图基本规则的处理上，相较于第一次做业反而显得并不太难。因此我但愿在后续的课程开展中作好难度的调控，好比像将第一次做业里继承关系的考察放到第二次做业中或许难度层次会更好一些。

 

（3）hack组的调整

       在咱们的互测环节中，hack机制并不会惩罚屡次hack同质错误的“狼人”，但在实际修复过程当中部分不当心点击“非合并修复”的同窗就会吃亏。因此在个人观点里，可否在现有的房间分配基础上创建一个相似“信誉积分”的榜单，将那些“狼人”尽可能同时集中在一个房间里，这样也能增长一些“狼人”屡次hack同一错误的代价，尽可能让咱们在互测过程当中能对准某个具体错误hack，而不是盲目去碰运气。