BUAA OO Summary4

OO Unit4 Summary

Part1:架构设计

image
image
image
以类图为例,封装MyImplemention类,实现UserApi的接口,同时关联classDiagram、sequenceDiagram、stateDiagram,在各自的diagram中实现功能,MyImplemention负责调用。
对于ClassDiagram而言,通过唯一的id映射uml模型元素,并进行图的创建,对于getClassCount()这种方法,可以直接在ClassDiagram中实现,对于getClassOperationCount(String)这种方法,在MyClass中进行二级实现,并由ClassDiagram调用。这种思路同样运用于诸如MethodDuplicatedException这种在类的基础上对方法做检查的二级异常的抛出
对于各种uml模型,进行再封装,实现自己的uml模型以满足额外uml解析的需要。
时序图与状态图类似。
对于检查重名的问题,通过再开一个HashMap容器,映射名字与多个重名元素来解决

Part2:架构设计思维及OO方法理解的演进

  • Unit1
    核心在于理解表达式运算过程中抽象实例的概念,在此基础之上构建对象。
    其中第一次作业解法比较多,可以单从多项式的角度出发,但难以实现对后两次作业的扩展。根本原因在于可以不断有新的算子产生,需要在多项式、三角函数的基础上再一次抽象。
    此外,递归解析也是很重要的方法,核心在于“一切皆是表达式”。表达式与算子的整体与分割关系是需要特别弄清楚的。
  • Unit2
    这一单元侧重点在于多线程,个人困难点在于轮询和共享对象的确定上,特别是轮询,存在不可复现的特征,往往难以排查,这单元还很大程度上学习了不少Profile工具用以诊断、评估程序以及性能分析
  • Unit3
    这一单元侧重点在jml,实际上更像是告诉我们对于工程来说如何扮演好架构、需求与实现的关系,以及沟通的桥梁(课程采用jml)。不过我们的核心在于实现,课程组出题。这一单元温习了不少图论的算法。
  • Unit4
    这一单元是uml图的解析,面向对象的特征似乎显得更加明显了,或许是因为经过之前的洗礼罢。

Part3:测试理解与实践

实际上,对于第一个单元,由于个人还在熟悉java的道路上,所以没有经过系统的测试。
对于第二单元而言,则是采用对拍的方法,并通过电梯与乘客的状态演变进行评测机的撰写。
对于第三单元而言,我则是专注于测试数据的生成与另一套代码的实现。对拍的条件不是一直都有的,或许总有自己干别人没干过的工程的时候,一旦没有完成同一项任务的第三方,两套方法实现就显得重要了。而这一单元的图论又由多算法可言,实现不同的算法,在结果上相互印证,增加可信度。
第四单元的时候,进入考期,个人比较繁忙,加上没有互测的要求,对于测试就比较落下了。

Part4:课程收获

课程内容特别充实,在代码量之中锻炼自我,头秃。但是最后的成就感还是很强的。

Part5:改进建议

  • 第一单元难度太大。从四个单元的角度来说,OO的作业并没有明显的递进关系,各单元之间是平行关系。但第一单元一上来就给了一个下马威,递归解析的要求略高,立马就丧失信心了,而且害怕OO作业,而后面几个单元则不会。
    解决:pre与第一单元具有强连贯性,一个是要把pre作业的重要性观念强化给同学们,否则之前较少接触java的同学上手第一单元很痛苦,最好给pre赋分,拥有总分的一定占比,同学们才意识到pre的重要性。并且第一单元考虑降难度,或者第一单元第三次作业设为额外加分。
  • 研讨课积极性不高。
    其实这始终与OO这么课程没有太大关系,大学不少课程都是这样。可以一直感受到课程组鼓励每一位同学表达、抒发自我,但最终始终是少有的几位同学不断起主导作用,其余同学不会有太多变动。
    解决:整学期固定分组,每人每次研讨需完成不同任务?
  • 研讨内容存在重复:
    研讨时每组均有同学上台,但很容易遇到小组观点与之前的观点一样的情况,但最终还是不得不硬着头皮再讲一遍,有几分不适。
    解决:像有几次研讨课,不同组就有不同的要求,所以最后重复会少的多,如果可以,课程组再费心给研讨课多设几种小组任务?
posted @ 2022-06-29 15:33  阿莫誒  阅读(9)  评论(0编辑  收藏  举报