针对第四单元和本学期所学的内容，撰写博客：
（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助教的，这些是我之前的一些想法。不过现在……再说吧