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