本单元总结

这一个单元主要建立一个UML的解析器，其中需要在理解UML元素对象的基础上完成一系列的操作代码。个人认为这个单元的重点在于——

• 理解UML元素和各个元素之间的父子关系
• 建立一种元素之间的索引关系
• 建立元素与元素之间的关系

通过这三个步骤就可以建立一个树状的索引结构。对于单个元素的查询利用索引找到元素，然后再通过树状结构来查询其相关的元素信息。其中会涉及到一些查询和遍历的代码。

给出一种结构如下：

四个单元的架构和OO方法演进

第一单元

第一单元是多项式求导，可能是最难的一个单元。原因可能是第一次正式接触Java，而且这一个单元的要求比较多，包括很多WF的考察。另外三次作业的难度递增，刚开始还不懂得迭代开发的技巧，所以第一单元基本上每次都需要重构一下。

而这一个单元主要采用的是最基本的面向对象思想，就是对于不同的对象建立属性域和方法域，然后进行构造就可以。总体上设计难度不大，但是需要小心很多正则表达式的坑和WF的错误。这一个单元还算比较顺利。

第二单元

第二单元是一个迭代设计的电梯系统，需要采用多线程的设计思路。其中把电梯和请求系统分为消费者和生产者，采用生产者-消费者模型可以基本解决问题。

但除了需要采用生产者-消费者之外，还需要考虑一定的调度策略，这里列出几种常见的调度策略——

1. FCFS：这也是第一次作业采用的算法，是一种随即服务算法，它不仅仅没有对寻找楼层进行优化，也没有实时性的特征，它是一种最简单的电梯调度算法。它根据乘客请求乘坐电梯的先后次序进行调度。此算法的优点是公平、简单，且每个乘客的请求都能依次地得到处理，不会出现某一乘客的请求长期得不到满足的情况。这种方法在载荷较轻松的环境下，性能尚可接受，但是在载荷较大的情况下，这种算法的性能就会严重下降，甚至恶化。
2. SCAN：扫描算法是一种按照楼层顺序依次服务请求，它让电梯在最底层和最顶层之间连续往返运行，在运行过程中响应处在于电梯运行方向相同的各楼层上的请求。它进行寻找楼层的优化，效率比较高，但它是一个非实时算法。扫描算法较好地解决了电梯移动的问题，在这个算法中，每个电梯响应乘客请求使乘客获得服务的次序是由其发出请求的乘客的位置与当前电梯位置之间的距离来决定的，所有的与电梯运行方向相同的乘客的请求在一次电向上运行或向下运行的过程中完成，免去了电梯频繁的来回移动。扫描算法的平均响应时间比最短寻找楼层时间优先算法长，但是响应时间方差比最短寻找楼层时间优先算法小，从统计学角度来讲，扫描算法要比最短寻找楼层时间优先算法稳定。
3. LOOK：LOOK算法是扫描算法的一种改进。对LOOK算法而言，电梯同样在最底层和最顶层之间运行。但当LOOK算法发现电梯所移动的方向上不再有请求时立即改变运行方向，而扫描算法则需要移动到最底层或者最顶层时才改变运行方向。

无论采用何种调度策略，一定需要注意同步与互斥问题，要对共享的变量进行保护。值得一提的是这一单元的学习和OS中多线程编程单元内容高度相似，两者相互强化了对于多线程编程的学习过程，这种体验还是挺满足的。

第三单元

第三单元是一个具有各种操作的社交网络系统的编写，不过我还是更倾向于称作是一次图算法的考察和演绎。虽然背景采用的是社交网络，但是大部分内容都是需要用到图论中的知识和算法来进行一系列的查询和对图的更改操作。

和大部分同学的体会一样，这一个单元对面向对象的考察并不是重点，反倒更多的是算法（毕竟是通过阅读JML补充一些关键函数即可）。这一单元主要的工作有两个——

• 阅读JML理解需求
• 写好算法

其中一些关键的算法包括——

• dijkstra
• Tarjan

这一个单元不仅考察了JML本身，而且也考察了大学学习DS积累下的算法功底，而且也考察了离散学习图论相关的概念。所以我也觉得这个单元是综合性最强的一个单元，自己也因为自己大一的漏洞在一个单元栽了一些跟头。同时也让我意识到作为一个软件开发者必须有充足的知识储备和综合应用能力。

第四单元

第四单元是对UML的一个考察，主要是UML中的类图、状态图和流程图中元素对象的分析。而这一单元的模式和上一个单元比较相似，也是填充一些关键性的操作代码，设计一些容器。这一个单元其实只要理解UML中元素的关系就行，主要思路是建立索引，利用UML元素既有的父子关系，建立一棵树。通过对于树的一些遍历、查询等基本的操作来完成对于UML元素的解析。

测试

• 第一单元第一次是纯手动测试，之后采用别人写的评测机进行了测试。
• 第二单元手动测试，测出了不少的bug。
• 第三四单元由于不会搭建评测机和手动测试的复杂性，只进行了一些简单的手动构造数据，基本测不出什么bug，算是摸了吧。

课程收获

在一个学期的Java学习过程中，我学会了如下的一些知识

• Java基本语法
• 规范化的代码风格
• 正则表达式
• 面向对象的思想方法
• 多线程的基本编程方法
• 一些常见的设计模式的原理
• 面向对象编程的SOILD方法
• 异常处理
• JML语法规格
• UML基本思想

学会了如下工具链的使用

• IDEA
• JUnit
• StarUML
• Git

另外我还自学了

• 函数式编程
• 代码重构原理

阅读了一些相关的书籍，包括

• Dive into design pattern
• 代码整洁之道

所以总的来说，这个学期学习的内容还是挺多的。但其中课堂上学习的东西比较多，所以相应的内容深度就略有不足。希望以后慢慢加强学习。

改进建议

1. 虽然名为面向对象课程构造，但是既然是一门编程课，考察算法无可厚非。但是相比于其他的单元，第三单元对于算法的考察有些太多，并且JML本身的滞后性，让这一单元不如前两个单元的体验感强。包括我在内的一些同学都反映不会再接触JML这个枯燥的工具。
2. 实验课：实验课把握好难度和时间，比如垃圾回收机制那一次实验明显出现了任务太繁重的问题，导致很多同学没能按时提交。
3. 对于后两个单元可以考虑将其改进成一种像前两个单元一样具体的实际问题，这样成就感和动力就更足一些。单纯的对JML和UML的考察显得有些枯燥乏味。
4. 互测：互测屋内的人数可以减少一些，比如3-4人最合适。因为对于像我这样的弱鸡来说不会写评测机，所以很多情况下只能手动互测，带来的工作量和复杂度让我之后就放弃了互测。如果课程组从一上来就默认人人都会造评测机，那课程还不如叫做”面向对象构造与评测系统构建“，我想人数少一点也能给手动测试的人减少一些工作量。（还请大佬们理解一下菜鸡）
5. 性能分的造成巨大的内卷，可以考虑减少性能分的比例。（不过哪怕比例再小，内卷怪还是会卷）
6. 理论课：OO的理论课程有很多内容讲的太”形而上“，缺少很多例子和形象化的说明。好多次和同学们交流都反映听了一节课好像听了很多东西，又好像啥也没听。很多内容听着也确实挺犯困的。
7. 研讨课：之后可能就不会再有线上的研讨课了，所以针对线上研讨课改进的建议就不提了。

线上学习体会

这个学期是比较特殊的一个学期，当然作为CS的学生，影响很小（反正基本靠自学）。而OO课作为一个编程课，除了上课形式之外，几乎没有什么影响。而且线上学习还方便自己随时查看自己不懂的地方。虽然对我们没有什么影响，但是助教和老师们的工作量丝毫没有减少，无论是平台搭建还是录制网课，都给课程组增加了不少的工作。这里还是需要感谢课程组，感谢一个学期以来的付出和工作！

OO第四单元暨课程总结

原文：https://www.cnblogs.com/haroldcheng/p/13158949.html