代码改变世界

OO summary Unit 4 & 课程总结

2022-06-27 20:22  BUAA_GreenDragon  阅读(10)  评论(0编辑  收藏  举报

Unit 4博客&课程总结

Unit 4作业的架构设计

本单元作业的设计我分为了三个模块处理:模型构建 + 预处理 + 任务函数,前两部分即为整个图的完整构建,第三部分即为实现题目要求的查询方法。

最终的文件树如下图所示:

 

 

模型构建

为了便于对于一些属性的查询以及避免与官方包内的数据类混淆,我为题目中遇到的每个UML元素都构建了自定义类,在拷贝过原有的属性后,另外新增了一些过程量表示模型图结点间的关系。以 UmlClass 为例,我构建了 MyClass 类。为了表示类图中的属性、方法以及其他一些中间变量,我构建了相应的容器并配备了查询方法。

除此之外,对于整体图模型的解析与构建,我采用了层次化解析的思路,即从上到下依次解析。例如对于类图元素,先解析图中的结点(类与接口),再搭建类图中的关系、补充结点信息(继承、关联、方法等),以此类推。层次化构建使过程非常清晰,且可扩展性也非常好。

 

 

预处理

因为本单元的任务完全是静态查询,数据在输入后不会发生变化,因此为了减少查询时的时间复杂度,我对一些变量采取了预处理的办法,在执行完模型构建后调用相应的 update() 方法。例如对类的继承深度 depth、类的间接属性、类实现的全部接口(包括直接与间接)等。

 

 

任务函数

任务函数即为预处理后对相关的数据的查询,这部分的具体实现内置在每个自定义类中,不必详细介绍。

三个模块完全依次执行,相互独立,耦合度低,且可扩展性很强。

 

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

架构设计

架构设计是OO课程中不可或缺的一环。以往程序设计的题目只是解决一个小问题,我习惯于拿到题目后直接上手,遇到问题时再去想怎么解决;但是OO课程每一个单元的作业更像一个完整的项目,代码动辄几百上千行,要想避免让代码变为屎山,就要求有一个清晰、可扩展的架构。因此在每个单元作业前,我都会预留思考的时间,仔细想想需求的层次、模块的设计、以及可能的扩展方向,力求在将来的增量开发中有更好的体验

像在第二单元的线程安全的设计中,我反复琢磨可能发生死锁的情况,对执行 wait() 方法的模块反复推敲,取得了良好的效果。

在第四单元的作业中,在拿到题目后,层次化解析UML元素、分层架构的思路就已经浮现在脑海了,我将所有的元素分为5层进行解析,先是类图、接口、顺序图,再是他们中的属性、方法、消息等,很快就完成了作业,足以见得架构设计给我带来的帮助。

 

OO方法

面向对象中封装性至关重要,是面向对象的灵魂。OO将需求拆解为各个模块,通过完善模块内容与处理模块间的交互来完成需求。这样的好处是:

  1. 层次化清晰,每个模块解决自己的活,分工明确,同时也降低代码的耦合度,利于维护与更改;

  2. 增强可扩展性,需求变化后只需更改相应模块的内容即可解决;

  3. 复用性强,模块作为一个整体可被反复调用;

 

测试方面

OO课程中的测试环节我都是按照以下流程进行:

  1. 利用样例代码与自己手动捏的较弱的数据进行测试,保证基础功能的完成;

  2. 针对易错、易超时的方法针对性构造数据强测,如Unit 3中图论的一些方法等;

  3. 与小伙伴对拍,利用大数据覆盖性测试。

在第一单元中,我没有使用测评机,均是采用上述一二步骤进行测验。由于构造测试样例的疏漏,我没有考虑构造输入为0的情况,导致在第二次作业中强测被扣了分。

在第二单元中,针对电梯请求的构造,我利用测评机生成覆盖性数据进行本地强测。但是可能由于测评机不够完善,导致在第二次作业采用共享队列时被hack了。

针对第三单元的JML测试,我用不惯Junit,实际上还是针对方法自己构造测试数据。因此还是采用了针对图论方法构造可能超时的数据进行测验,第三单元强测均满分。

第四单元细节繁多,的测试主要以和小伙伴对拍为主。先用超大数据进行强测,而后生成对应的针对性数据找bug,效果不错。

 

课程收获

  1. 学会一门新语言——OO课程帮助我了解了java,不仅包括基础的java语言,还包括UML类图、JML规格等。通过第一到第四单元的作业,我已经能够熟练使用java编程,并轻松地debug;

  2. 一帮好友——OO课程作业设计十分巧妙,有许多值得推敲的点,上到架构的设计、模块的构建,小到具体算法是实现,都是值得讨论的地方。在于他人交流的过程中,我感受着思维的碰撞,与同学们相互交流,也让我结实到了许多优秀的同志;

  3. 对于层次化架构的理解——设计层次化的架构是面向对象编程必不可少的环节,简约、清晰、易扩展的架构能节约很多时间。在拿到需求后设计模块、理清楚逻辑关系是首要环节,否则很有可能在后期的迭代开发中面临要么重构,要么堆屎山代码的选择。层次化架构的分析不仅是OO的一种思想,也是一种人生哲理啊!这告诉我们切勿想着一口气吃个胖子,要做好规划。

 

改进建议

  1. 我认为寒假的预习板块可以改进一下。可以看出该部分是为了承接第一单元表达式计算的作业而设计的,花费了很多篇幅去讲解正则表达式的格式以及UML类图的设计,但是花费一个单元共5讲的内容来介绍正则表达式有些冗长。我认为可以将第三弹的内容进行压缩,达到熟悉正则的目的即可,并相应地增加一个预习第四弹,可以介绍一些常见的设计模式(如工厂模式、单例模式等)。OO课程的目的最终还是培养面向对象的思想、架构设计能力,这样也可以契合培养方案。

  2. 我认为对于讨论区以及微信群的交流与答疑方式可以改进。据实际体验而言,微信内的答疑效率非常低下,许多人不翻消息记录,会有大量的重复提问;讨论区的相关板块十分杂乱,没有索引结构,助教老师回答采用 “引用原话+回复” 的方式不够清晰,导致在“针对指导书提问”这一个栏目给人观感十分臃肿、不清晰。我认为可以将一些针对指导书内容的提问局限在讨论区,微信群仅用于其他交流,再为规范讨论区的结构,建立清晰的索引结构,提高同学们提问、查找的效率

  3. 研讨课上一些内向或摆烂的同学不积极发言,全程混讨论,没有自己的观点,享受他人思维碰撞的果实,这是不公平的。我认为可以对研讨课环节分数的评定进行一些细化,如会议纪要中写出每个组员贡献的思想并以此评议每个人的分数,再根据小组代表发言的内容进行小组加分,细化为个人与团体分,可能大家积极性会高一些。