End Game----OO最后一次博客作业立足于自己的体会给课程提三个具体改进建议建议列表

针对第四单元和本学期所学的内容，撰写博客：

（1）总结本单元两次作业的架构设计

（2）总结自己在四个单元中架构设计及OO方法理解的演进

（3）总结自己在四个单元中测试理解与实践的演进

（4）总结自己的课程收获

（5）立足于自己的体会给课程提三个具体改进建议

---

总结本单元两次作业的架构设计

第一次UML作业

基本上就是一个类模拟器。

UML里面其实也给了很多存储数据的结构，为了能用上这些数据结构。我选择对几乎每一种元素都新建一个自己的类去包裹起来。比如“MyClass”

可以说是没有什么难度的一次作业，只是容易被小bug所坑（一个bug把我坑了60分）

第二次UML作业

就是三个大模拟器。类模拟器，交互模拟器，状态图模拟器。

最后合并成一个大的输入输出类。基本架构可以看下面。

难点在于如何理解这么多概念，还有如何在那么多的类中进行debug

总结自己在四个单元中架构设计及OO方法理解的演进

第一单元的主线是求导。

• 第一次作业，很简单的加法求导，就直接面向过程去完成了。用了很多简单粗暴的字符串替换+BigInteger的异常去判断是否格式错误
• 第二次作业，加入了sin、cos等的求导。所以要开始分拆成几个类去分别计算了。不能一个大类走天下。然后还赶紧补课了正则表达式
• 第三次作业，主要是加入了嵌套。这个的难点是对于数据的解析，而具体求导反而没难度。也就是建成一棵表达式数的样子。

第二单元的主线是电梯，说实话，感觉这个单元设计得不合理。

• 第一次作业，傻瓜电梯，看懂题目，看懂需求之后一个小时直接写出来。甚至单线程直接弄的那种。
• 第二次作业，也是一样的单线程。
• 第三次作业，突然变成了多线程。并且电梯能去的地方比较迷，造成程序中的一个小bug就炸了40分

第三次单元的主线是最短路

• 第一次作业，划水容器
• 第二次作业，过于相信官方容器的速度，炸了
• 第三次作业，架构设计得太丑，导致写了三次

第四但愿的主线是UML

• 第一次作业，读了半天的题目，后面很快地写了一个类模拟器。不过由于对指导书理解有误，一个bug带走60分
• 第二次作业，题目还是得读半天。写出了仨巨大的模拟器。中间被卡的地方是关于找环的地方被卡了，不过后面发现暴力也能过。debug花费的时间比写代码的时间长多了，后面发现是一个变量写错的弱智bug。最终得了满分

总结自己在四个单元中测试理解与实践的演进

第一单元

• 自己手动做各种极端数据
• 加入了嵌套之后，做丧心病狂的嵌套实验
• 对于正则表达式上可能存在的点进行攻击

第二单元

• 各种极端带人的情况，比如边界楼层。
• 压力测试，比如来回往返
• 特殊楼层的测试，比如3楼

第三单元

• 从同学那里拿来了一个对拍器
• 还有一个数据生成器
• 一拍死一片

第四单元

• 逻辑验证
• 做带复杂环和复杂继承实现的图进行验证

总结自己的课程收获

• 会用了JAVA的基本操作
• 会抛异常了
• 除了计组之外，第一次多个文件多个类协同
• 继承，接口什么的概念熟了点
• 对于架构设计略有提升

立足于自己的体会给课程提三个具体改进建议

（正片开始）

其实之前的内容我写得比较简短，是因为感觉其实之前的内容单独写不是很好。所以我把一部分内容把我课程的感受和建议放在一起写。

我个人对OO课程的理解是，课程设计希望我们在课程结束之后能利用面向对象的方法，写出架构比较好的程序。

架构比较好的程序有一个特点就是可扩展性好，所以才有了每一次的增量式作业。

但是课程设计上也存在着一定的问题。

对基本知识的教学缺乏

面向对象这门课程，首先和之前的一大不同就是，语言变了。虽然JAVA比较好上手，但是相较于C语言而言，还是有很多习惯上的不同的。

而继承，多态，接口实现等各种面向对象里面较为关键的知识点，教得也很少。至少最后一次作业前，我问了几个同学，他们大多还都不知道接口到底有什么用。UmlClassOrInterface这个东西的容器既可以塞Class又可以塞Interface也不清楚。

缺乏对于基本知识的教学，就会使得在前期写作业的时候把更多的心思放在“我该怎么把我的想法转换成代码”，而不是“我该怎么去设计我的代码”。并且，基础运算语句之前我们的课程都学过，这个都基本没什么问题，只要把代码转换成JAVA的代码就好了，而面向对象的思想我们之前是没学过的。并且面向对象的这些基本工具都没掌握的情况下，是比较难设计出好的代码的。

对以上两点，课程设计中给我们安排的“教学关”分别是：暑假的A+B作业，上机实验中的员工机制设计

A+B类型的作业，基本没什么锻炼意义。就是掌握了很小一部分的JAVA写法。

上机实验中的员工机制的设计还比较适合练习，但是上机时间过短，没有充足的时间来进行学习+实践

对设计方法教学的缺乏

在这里，我指的是各种设计上的思路。比如工厂模式，观察者模式，单例模式，以组合代替继承等。

缺乏这些基础的设计思想，难以使得学生在对题目进行思考的时候，站在一个比较高的角度去思考。站在一个总体的角度去考虑架构。

单例模式在最后的UML作业，合并终止状态和起始状态的时候用到了。而这个方法还是在刘禹老师的C++课程里面学到的。

以组合代替继承这个方法没教，造成在图作业里面，傻乎乎的直接继承了上一次的代码，造成父子类十分混乱。

工厂模式没教，并且接口，抽象类什么的没教好。求导第三次作业，我为了避免错误（因为我当时上二学位，只有一天多的时间去想并且写完一周作业），只能暴力把所有的类型给合成一个大类，然后Switch暴力判断。其实如果用一下接口什么的，会把代码弄得很简单。

作业设计内容不合理

电梯是第一个需要说的。

电梯系列作业的训练目的是多线程的处理。然而前两次作业是单线程。就是主控和电梯两个线程，而主控基本不用干什么事情，最多也就是唤醒一下电梯。所以起不到训练多线程能力的效果。

而第三次，直接加上多电梯，并且这仨电梯还特别诡异。而前面没怎么训练过相关的内容，造成写起来比较的难受。虽然也有粗暴并且能过，分数也能得80+的方法，但是总感觉效果不好。

知识点考察杂揉

求导作业，应该是难度最大的作业。

但是难度并不是在如何求导，而是在如何解析运算式上。

我觉得这一个部分更应该考察的是，我们如何设计出一个架构以存放表达式，然后这个结构还要能很方便地对表达式进行求导。答案很显然，表达式树。只不过这个树用到了面向对象的各种思想，多态，继承之类的。

但是同学们做这一部分的时候，普遍的重点是，正则表达式怎么写。怎么解析字符串。而这些点都是十分之细节的点，容易陷入其中。对的，这一部分的内容，如果学了递归下降法会好写得多。但是现实的问题是，我们不会，老师没教，助教没教。

求导作业这一章，我真的除了学会了抛异常（这个其实我在暑假作业的时候学过了），书写比较复杂的正则表达式（JAVA还不支持平衡组，否则可以大正则把第三次作业给干掉了），就真的没学会什么。

架构的问题，由于试错成本高，想出了可能比较精妙的架构，也由于怕出错而不敢用。

JML教学效果不行

课程现在已经可以说是结束了，但是我对JML的理解目前是“一个据说很精妙，但是很难用，平时没有使用价值的东西”。

对，老师上课说了很多JML的优点，说了可以用来进行形式验证什么的，非常棒。

但是这玩意儿属于比较小众，或者按照助教的说法是，比较高端的东西。这也就导致了资料少，说明少。配置复杂。

我原本的期待是，能通过JML，自己对自己的代码写一份，然后用来进行形势化验证。而最终的结果是，光是把JML的相关程序给跑通我就花了很多的时间。各种奇奇怪怪的错误，易用性差。

在做课程介绍的时候，也没说要怎么写代码，怎么配置JML才能让它正确运行。

一个强大，但是我们无法掌握使用方法，无法简易使用的工具，在我看来和没用的工具是一样的。

JML就我个人感觉，就差不多是用半离散数学的方法去写函数需求罢了。我相信JML是有很强大的形式推理功能的，但是我不会用。

顺便提一下，当时的博客作业，要求生成测试代码。我按照讨论区里面同学的代码生成了一份测试代码，然后跑了一下Path这个类。结果发现官方的JML描述里面没有明确一些极端情况，比如说传入的参数是NULL的情况该如何处理。造成必然有几个点是Fail的。

我不清楚Fail是正常的，还是官方的JML写漏了。

UML教学效果不行

我感觉，如果真的想让我们去学习，去理解UML，更好的方式是让我们去操作UML的软件，或者去画UML图，或者去对一幅UML图给写解析报告。

UML的两次作业，只能说是一个弱化了的大型图模拟器作业。对UML的理解，其实并不多。

写完了这个作业，仍然不能学到，UML为什么要这么设计，UML的好处是什么。

上完UML第一次课之后，马上是上机操作。而上机操作中，我的感受是，UML这玩意儿太自由了，以致于我不知道怎么画。

在JAVA真正的码代码的时候，语言的限定就规定了我要怎么样去写。而UML图里面，什么可以省略，函数需不需要写返回值。这些细节的东西我感觉很迷茫。

我甚至一开始不知道状态图怎么写，交互图怎么写。而UML的检查规定，我也是同学告诉我，StarUML里面有这个检查是否合法的功能。

我还没真正运用UML去做一些什么东西的时候，突然就让我对UML图进行解析了。我是感觉非常的奇怪。

这样子虽然我做了之后，很清楚UML图里面是怎么构成的了，但是我并不清楚，UML图的一些设计原则是什么。

评分机制的不合理

不过先得说，看到网上对于之前OO课程的评价，今年OO课程的互测方式什么的，真的提升了很多。

但是不代表现在的这个机制就一点问题都没有了。

互测机制的目的是想让我们互相发现bug。但是这个bug具体是怎么发现的呢？

至少从我的了解来看，第一单元之后，就没有什么人去读别人的代码进行找bug了。而能稳定进A组的同学，大部分靠的就是暴力对拍。因为一个房间里面的代码太多了，不可能有精力全部看一遍。

所以从最终的效果来看，同学在这个过程里面，其实所做的不是找bug。而是去制造测试样例，找到能炸掉某个程序的样例之后就去提交。而这样子找到的bug，很多同学说“一发带走”。

也就是说，其实很多bug是同一个bug，只不过刚好很多测试数据去测他了而已。今年的这个修复bug的机制解决了之前的狼人抓住一个点疯狂刀的行为。但是没解决另一个问题。

官方的测试数据集中地打中了一个bug

有一个很有意思的情况，同学们随机生成的数据，如果被一波带走了，会被说成是同质bug。而官方的数据炸了很多个点，这个bug被一波带走了，被说是这是个严重bug。那么问题来了，同样是测试数据，为什么官方的测试数据和同学自己的测试数据就区别对待呢？

建议列表

• 在开始增量式作业之前，划出一部分时间用于基础知识的训练
• 设计至少一个单元的，自顶向下而不是自底向上的增量式作业
• 把求导作业分成两部分，一个部分是通过标准接口去读取，然后求导。另一个部分是写这个解析表达式的接口
• 上课的时候，增加部分具体的实现代码。
• JML官方给出具体的，可以用来形式验证的样例。并且给出全套工具的使用方法。
• UML改为，或者部分改为真正去绘图，书面分析的作业
• 强测扣分和互测扣分机制统一。不过权重可以修改。比如现在互测是，扣分=修复的bug数*1+未修复的bug数*2。那么强测可以变为扣分=修复的bug数*5+未修复的bug数*10

现在大概的建议就这样了。学期刚开始的时候，我还想着以后当OO助教的，这些是我之前的一些想法。不过现在……再说吧