OO第四单元总结

OO第四单元总结

1.第四单元架构设计

1.1 第一次作业

第一次作业涉及到的是类图的指令,考察我们对类图中元素的理解。在一开始的数据处理上由于数据传入具有不确定性,我会将元素进行多次遍历,根据元素之间的父子关系构建关系图——第一次遍历是UmlClassUmlInterface,第二次遍历是UmlGeneralizationUmlInterfaceRealizationUmlAttributeUmlOperation,第三次遍历是UmlParameter

在数据存储方面,我会对部分元素用两个Hashmap进行存储,一个的key值是id,另一个的key值是namekeyidHashmap主要用于进行关系图的构建,毕竟类图元素给的信息都是id。而key值为nameHashmap用于指令查询,为应对name重复的情况,value值类型用ArrayList

为了对元素进行扩展,我编写了MyClass等新类,既能保存类图元素信息,也能增添新的属性。

在查询指令方面,需要注意的是在计算耦合度是若ReferenceType引用的类或接口是当前查询的类,则耦合度不增加,否则耦合度增加1。总体指令难度不大。

1.2 第二次作业

第二次作业增加了顺序图和状态图的内容。总体架构和第一次作业类似,依然是元素分类储存+关系构建的模式,最后具体指令具体分析。

比较复杂的指令应该是关键节点的判断,这里我就用了朴实无华的DFS遍历算法,根据能否到达Final State来判断是否为关键节点。这里我没有特判如果一开始就到达不了Final State的话,所有节点都不是关键节点的情况,导致强测错了一个点。

1.3 第三次作业

第三次作业是有效性检查,因为有效性检查只需检查一遍,所以复杂度基本不需要考虑,只要保证正确性即可。

比较难实现的指令一个是循环继承,这里我将类和接口分开处理。因为类没有多继承,因此在DFS遍历时一但找到环皆可结束递归,记录环中元素即可。而对存在多继承的接口,则需要找到以某个节点开始的所有环,然后进行分析。

第二点难点时重复继承。因为已经排除了循环继承的可能,因此类不可能多继承,只需考虑接口。一个节点出现多继承的条件就是DFS遍历时某个节点出现两次,遍历时要设置一个容器储存到达过的节点,且返回的时候不需要remove

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

2.1 第一单元

第一单元的任务是完成一个表达式解析器,实现对表达式拆括号和化简的能力。在这一单元我主要应用了递归下降法,建立由表达式、项、因子层层嵌套的树状结构。

这一单元难度较大,一方面作为初学JAVA的第一个任务,继承,容器,正则表达式匹配等面向对象的概念和技巧都要在这一单元应用。另一方面解析器任务具有很强的拓展性,表达式涉及到了乘方、三角函数、函数等复杂形式,在化简上有很多优化的空间。因此在完成这一单元既要有好的架构,具有良好的可拓展性,保证在迭代开发中不至于重构;另一方面要细心,考虑到多种复杂情况,对多种表达形式逐一分析。

2.2第二单元

这一单元的任务是实现多线程电梯交互系统,可以说是最难的一个单元了。难点在于要实现多个线程的同步和互斥,找到类与类之间的共享变量,使用wait-notify的编程技巧,避免出现轮询。

这一单元也有性能分部分,在电梯算法上我选择了纵向电梯LOOK算法,横向电梯ALS算法。因为轮询问题已经够头疼了,我就没有对算法进行更细致的优化。为了实现互斥同步,我对共享变量的所有方法采用synchronized同步锁。

总的来说,这一单元让我明白了线程之间如何相互合作,并行运行。真正到实操的时候才发现多线程的实现原来这么复杂,稍微处理不好就会有很多问题。

2.3第三单元

这一单元是考察对JML的解读以及实现,载体是一个简单社交关系系统。这一单元相比于前两个单元要简单不少。当然由于有时间限制,在功能实现上要考虑到复杂度。比如运用对优化,并查集,Dijkstra算法等来降低指令查询速率。

虽然本单元类似翻译题,但在课上小测编写JML语言时我意识到要用具备严谨性的JML算法去描述一个函数时是多么困难,要考虑到类当中的很多成员,以及用严密的语言来描述这个成员变化。心里不由得敬佩写第三单元JML的助教了。

2.4第四单元

这一单元考察UML语言的理解。所有指令都是基于围绕顺序图、时序图、类图中的各种UML元素展开。指令的实现本质也是考察我们的图论知识。通过这一单元我也认识到一个UML图有这么多要素构成,这其实也是对一个大的对象层层拆分,变成一个个具备统一性的小对象,正是面向对象的思想。

3.测试的理解与实践的演进

在第一单元和第二单元我主要采用自己构造边缘数据来进行测试。在第三单元依靠同学的评测机生成数据来进行对拍,在第四单元由于临近烤漆,只能简陋地构建几个数据进行测试。说来惭愧,本学期在测试方面主要是依靠手动构造数据,没有多少搭评测机的经历,主要原因也是本学期任务较重,完成任务之后就没剩多少时间了。

但总体来说,手动构造测试数据也算一种能力,思考代码压力点,进行压力测试,寻找数据边缘点进行准确性检测,这些还是挺有意思的。

4.总结自己的课程收获

一方面,面向对象提高了我分析问题,解决问题的能力。每周拿到一个任务,分析其功能实现,思考需要一个什么样的顶层架构以及什么样的对象,如何描述对象的属性等等。这种能力是在这高强度的代码训练中得到提升的。

通过面向对象,我明白了一个好的架构要具备优秀的可拓展性和层次性。可拓展性使得在迭代开发中不会进行大规模改动,利用架构层次对对象信息进行分装,简化自身的代码。

5.改进建议

1、可以在pre增加搭建简易评测机的课程,因为这门课很依赖评测机的搭建。

2、适当提高中测强度,有些单元的中测感觉强度太弱,甚至出现中测全过强测全寄的情况。

3、研讨课强制发言制度有些不合理,一方面一门课有十几个小组,但其实大家讨论的内容很多都是重叠的,在十几分钟内往往讨论不出个所以然,就经常会出现有些小组要讲的东西被前面的小组讲完了,无话可说的情况。同时由于时间限制,有些小组有很多想法但不能在短时间内全部分享出来。建议发言还是遵从自愿原则,增加奖励机制。

 

 

 

posted @ 2022-06-29 09:05  鹏程万里orz  阅读(7)  评论(0编辑  收藏  举报