-
PART 1 架构总结
三次作业的uml类图如下
在第一次作业中,在有关继承以及实现等的方法上,我使用递归的方法来解决问题,这次作业中官方要求的方法不适合直接用于递归,一是抛出异常时需要最开头的类名,其缺少相关参数,难以实现,另一点是递归过程中可能出现非必要的异常,故我写了若干的myget方法,弥补了以上问题,第一次作业重点在于细致观察,认真研读和思考数据限制,虽然工作量很大,但是还是可以顺利完成的.
第二次作业的难度相比于第一次作业来说小很多,本次唯一的需要设计算法的是排查关键状态,这里我直接使用了暴力dfs,本次作业其他方法较为简单,但是问题在于我三个图汇聚在同一个实现类中,显得有些过分庞杂了
第三次作业的实现难度比第二次要多太多了,引入了9个异常,基于第二次作业,我先是拆分了实现类,分别用myclass,mystate,mycol解析类图,状态图与顺序图,此次作业感觉最难的还是循环继承这里,不得已再次使用了dfs解决了问题.
-
PART 2 课程架构思维及oo方法理解
四个单元我们经历了多项式解析,多线程电梯模拟,基于jml规格的程序设计,以及uml解析器设计,四个单元个人心中难度是1约等于2>4>3,第三单元简直是我的白月光。下面我将总结各单元的架构思维以及带给我oo的理解。
第一单元的关键思维是层次化，本单元表现为递归下降：表达式到项到因子，复杂程度递减。第一单元个人的难点在于处理各部解析中peek与步进等的关系。本单元两次失败均在于自己没有很好地阅读以及理解指导书，比如第二次作业中，我就没有考虑f(x)多次出现的情况,导致了失败,这个单元的最大收获就是明白了一定要好好阅读项目需求,同时学会层次化思维。
第二单元的关键思维在于并发，多线程是更符合实际开发的模式，当然因为此前并没有实际开发与学习经验，加上清明假课业过重，心态浮躁，第一次作业差点又挂掉，至少是出现了交同一段代码两次结果不同的神奇现象，让我哭笑不得。好在在巨佬的经验分享之下我审视了自己的方法，终于安全地实现了运送。
第三单元的关键思维在于规格，我们需要避免自然语言的二义性，尽量准确描述需求，这样检验就变得简单起来了，本单元最难的事情其实是完全读懂并理解规格，这个对逻辑严谨要求是不小的。
第四单元的关键思维是模型理解，我们需要对uml抽象的图形模型进行代码上的理解与表示，同时需要对不同类型的图进行区分，本单元的算法我只用了dfs，此处感谢wzm哥哥在第一次作业我陷入绝望时提供的对拍数据。本单元让我学会了用抽象的，代码的角度去看待问题，这是重要的思维。
-
PART 3 对测试的理解以及实践改进
在四个单元的作业中，我的测试数据来源主要就是测试样例，自己嗯造数据的能力不强，因而也没咋hack人，假期想学着做一下评测机。需要强数据的点感谢几位大佬朋友的帮忙，提供了他们设计的几组合法的数据。oo个人感觉整体的测试层次性强，也隐藏了部分难点，过度依赖样例而自己不动脑的情况。经历了第一单元的折磨，我是学会了好好研读指导书了，终于不至于次次被重拳出击，自己不会构造太多样例，但写的时候会考虑那些合法但有病的数据的存在，可以说通过折磨，我开始能够小心地解决酒吧点面包的问题了。
-
PART 4 课程收获
本课程的收获在于一种编程思维——面向对象，两种重要能力的提升——编程与抗压，三个月的有意义的奋斗，以及四种oo思维的理解——层次化，多线程，规格，模型。这三个月和伙伴们经历过一起刷夜奋斗但因为思考不足仍然挂掉的惨痛日子，也经历过觉得大佬朋友不在指导就觉得自己做不出来的绝望。但是我纯粹依靠自己的思考还是做完了该做的任务。这三个月的苦痛让我绝望，但也增强了我的自信。
-
PART 5 建议
要提三点对oo这门课除了降低难度以外的建议的话，个人有如下想法。
研讨课可以分为展示部分以及协作直观任务部分，讨论课上很多时间其实组内绝大部分成员并没有有效参与,而且每次如果不是很好量化的任务总是相互推诿,这不应该是oo这门课所提倡的协作,可以把任务设计的更具体,压缩一部分对作业的讨论时间
可以考虑完成更多更新的设计,期末在github浏览发现了前辈留下的oo很多作业的评测机,有些除了数据限制其实是完全能直接用的,可以考虑创新题干设计,避免过度依赖前人代码。
平衡课设难度，这里并不是希望oo降低难度，而是希望oo能够调节第一单元与第三单元部分作业的难度，刚入门的时候难度过大确实是留下了不小的阴影，第三单元又有些太摸了，当然可以考虑设置更多有效的训练任务来弥补这些
