OO第四单元总结

OO第四单元总结

本单元作业的架构设计

第四单元的作业并没有重构,这也导致了个人看来,最后的框架是有那么一点不好看的。

整体的思路是现在Myhandle类中,进行读入的处理,考虑到输入的次序并没有与UML类相关,采用了多个循环,由于UML本身是有一定的层次性的,按照这样的层次性进行读入,比如先读入UML_CLASS,再读入UML_GENERALIZATION

根据需求对具体的MyclassMyInteface等来自UML元素的类进行了具体的设计,比如对于UML_ASSOCIATION由于指令中使用较少,主要在仅在最后的错误查询中有所应用,所以仅仅在Myhandle类在读入后,存了相关的end的id,方便于寻找类对应的UML_ASSOCIATION_END,而对于UML_CLASS则采用了如下的结构

public class MyClass {
private UmlClass itslef;
  private MyClass thefather = null;
  private String father = new String();
  private HashMap<String,MyInterface> interfaces = new HashMap<>();
  private HashSet<String> son = new HashSet<>();
  private HashMap<String, MyOperation> operations = new HashMap<>();
  private HashMap<String, NameableType> attributes = new HashMap<>();
  private HashSet<NameableType> attributenames = new HashSet<>(); //attri ref
  private final Visibility visibility;
  private String name;
  private String id;
  private HashSet<String> allinter = new HashSet<>();
  private boolean haveinterend = false;
  private HashSet<String> attriname = new HashSet<>(); //attri name
  private HashSet<String> endname = new HashSet<>();
  private HashSet<String> repeat = new HashSet<>(); //attri & end repeat name
  private HashSet<String> allfather = new HashSet<>();
  private HashSet<String> allson = new HashSet<>(); // allfa allson for tag3

各个数据的存储,都是为了特定的指令而服务的,由于担心动了原本的数据结构会影响前面的指令,其中的结构是否可以优化并没有加以考虑。而且根据需求每次再添加新的结构,总觉得会在多次添加之后导致整体结构的臃肿,但是提前的知道未来需求的添加又是不可能的,之间的平衡感觉是一个难题。

而在整体结构上,第一次是直接在MyImplementation中进行了处理,第二次和第三次,考虑到整体的结构,对时序图和状态图的处理以及有效性检查,则分别设计了用于处理的类。但对类图的处理沿用了第一次的设计,没有改动。虽然这样的设计也是可行的,但是还是感觉不好,也是第一次的设计对于后续的添加考虑不当导致的。但也是接近考期,因为时间安排原因,没有进行修改。

对于有效性处理的类,感觉个人设计的也是很乱的,主要是存在一个不同有效性的判断在不同的步骤处理的问题,比如对接口属性的pubilc的判断,实际上在读入处理的时候就可以直接进行判断,但是对于重复继承之类的,却是要所有的继承都读入才能判断,是否要牺牲对于判断的简易性换取结构上的统一,我觉得还是要考虑的。

四个单元中架构设计思维及OO方法理解的演进

第一单元

其实第一单元在当时对于面向对象,是没有太多的感觉的,尤其是第一次作业,个人感觉面向过程的痕迹是很重的,整体的框架就是一个处理输入然后输出的主函数,利用递归处理表达式,加上factor之类参数的类,还有像是仅仅作为工具的类,就是为了像面向过程中使用一个函数一样。对于类的理解,更多仅仅是带了方法的结构体,像是提及的继承什么的,也没怎么用,因子之类的类,并没有利用到课件中给出的那些继承之间的结构关系。

第二单元

个人感觉在第二单元,可能是对面向对象的理解加深较多的一个单元。可能是因为电梯、乘客这样的概念更加的接近传统意义中“对象”的概念,各自“状态”的这个概念也更好的理解,从而到整个面向对象的理解。同时还有多线程,也是第一接触,线程安全、锁的设置,也是学到了很多。还有对于设计模式的接触,也是在这个单元学到的比较多一些,比如主体的框架直接使用了在实验中提供的生产者-消费者模式,还有单例模式等等。还有在框架方面,也采用了电梯的策略的作为电梯类的属性而不是直接写在电梯类里面,方便对于策略的跟换,以及其他类型电梯的增加。

第三单元

在第三单元,更多的就是按照JML实现具体的函数,也因此吧,个人感觉上框架设计方面并没有特别的注重,就是按照着JML对于单个的函数进行实现,个人感觉作业的考核也反而让我去复习了一下图论的一些算法。还有感受比较深的是JML的书写确实还是挺难的,可能也是不熟练。

第四单元

实现一个UML的简易解析器。单单就论架构设计思维及OO方法理解,我觉得自己的进步可能像第三单元一样也不是那么的多。架构设计具体的在上面也有提及,不再赘述。OO的理解方面,可能更多的是UMl本身,给了我看面向对象的一个更多的视角,类图、状态图等等。

四个单元中测试理解与实践的演进

四个单元下来,还是体验到了测验的重要性。

第一单元是第一次接触到较为完整的测试,随机的生成数据,然后利用python自带的库进行结果的比较,并且结合一些自己手动构造的特殊数据。第二单元的正确性判断相较与第一单元就会复杂一些,并且由于多线程的原因,感觉测试的效果也并不是像之前那么好了,在有bug之后,精确的定位也比之前要难了,更多的依靠肉眼看了,还要考虑性能方面会不会导致卡tle的问题,主要依靠手动构造一些特殊的比较耗时的数据。第三单元则是了解了Junit相关的一些,进行了一些测试,结合JML的要求,不过数据方面还是依靠之前的方法。第四单元则是由于期末的原因,更多的就是手动构造了一些数据进行了简单的测试。

课程收获

在一个学期的学习下来,感觉总的来说,还是收获非常非常多的。

先是学了Java,学习了相关的一些语法,至少也是能稍微用用了。

还有或许是这门课最想传递的面向对象的编程思想,自己也是第一次接触,但是在这一个学期下来,至少了解了基本的思想。还有多线程、JML、UML这些课程知识,不再一一展开了

还有就是锻炼了自己单纯的写项目的能力吧。一个作业的完整的完成,从开始的需求的阅读,到整体框架的设计,再到具体的细节的实现,中间然后又可能意识到需求是不是哪里理解错了,框架的设计有问题,自己实现不了。再到完成后的debug部分,对于自己代码的测试。整个流程,在一周周下来,也算是稍微的熟悉了。包括单纯的写代码的能力,也是有所提升。

还有自己的心态和抗压能力,在一定的时间内要写完代码,还有在怎么都找不到bug而不得不找bug的时候自己的心理的调节。

也感受到了和同伴的相互交流的重要性,很多东西其实远比自己想的简单,自己常常会走入思维的死胡同。

改进建议

1.

第一单元和pre之间的差距感觉过大了。个人认为pre讲的东西相较于在第一次作业直接开始使用的java相关的内容,差距过大了,同时还要考虑表达式的解析之类的问题,对于刚刚上手java的我挑战很大。我觉得可以增加pre的内容,一个是更多的java教程,毕竟还是有没有学习过的,尽管学生自己也可以找到java的相关教程,但是我觉得由课程组提供一些资料、题目对于学生的学习是更好的。同时也可以介绍一些比如递归处理的思想,既然对于正则表达式都有所介绍,我觉得像递归处理也可以介绍,来减少突然增加的难度。

2.

第三单元JML的作业,感觉过于偏向考察算法方面了。个人理解这个单元更多的应该是让我们去学习和练习JML,无论是根据JML要求写代码,还是自己写JML。但是第三单元的作业方面,更多的时间反而花在图论方向算法的一些性能优化,感觉是否可以降低一些性能的要求,不是去卡ctle,我觉得这不是这门课在教JML的时候要主要考核的。反而对于JML书写上面的一些规范,个人感觉讲的还不是很多,也可能是我自己没能很好的理解。

3.

实验课和研讨课,感觉都可以有一定的改进。实验的结果,觉得是可以返回给学生的,不然连自己做的对错都不知道,感觉影响挺大的。研讨课,课上时间不够的感觉明显,一个是给同学们讨论的时间有限,一个是展示小组较多,尽管限制了每个小组展示的时间,但是感觉很少有在时间之内的,确实分享的东西是比较的多的,短时间肯定不能讲完。是否考虑压缩小组个数,或者改变展示形式,比如在课后以文字形式和大家分享。

posted @ 2022-06-28 23:00  strly  阅读(9)  评论(1编辑  收藏  举报