前言
理论上，这是本学期最后一次OO作业。虽然告别了OO课程，但是没有与OO说再见。我将在这次博客中总结针对第四单元的和本学期所有作业，分析自己代码能力和架构能力的成长。
四单元作业架构总结
两次作业中我都采用了“树形”的代码架构。对于每一条指令，我会让顶级父类向下传送“信号”，直到最底层获得执行结果。这两次作业我都没有进行明显的优化，导致第二次作业的强测中有一个测试点出现了超时的情况，很可惜！
-
第一次作业
从左至右分别是包之间的关系（整体架构关系）、UmlClass类内部的结构和继承map类的结构。
下面我将描述代码架构：
- 将MyUmlInteraction当作交互平台使用，其受到请求时向Storage类中查询；
- Storage中保存所有MyUmlClass/Interface（我没有区分类和接口），并保存fatherMap类存储类之间的继承关系；
- MyUmlClass存储attributionStorage和OperationStorage；
- OperationStorage中保存类的parameter；
- fatherMap中存储接口实现Map和关联Map；
总体上讲，我在建模时尝试“恢复”java中这几种UmlElement的相互关系，因而形成了多层的结构。不过我认为自己对继承图和接口关联图部分没有处理好，导致此处代码看起来很混乱。其他类基本上都是很清爽的。我还尝试用工厂模式对几个图进行构建，但是各种原因最终没有成功。
-
第二次作业
从左到右分别是包之间的关系（整体架构关系）、状态图内部结构和顺序图内部结构
这一次我依然采取了和上次类似的形式，创建了和fatherMap类同级别的StateMachineMap和InteractionMap。因为我认为类之间的继承关系、状态机类和顺序图类是平行的关系。这次我尽自己的力量去最大化解耦，但是还是由于算法的问题，导致代码十分的鬼畜。不过在状态图和类图，都存在一个Map和一个Storage存储映射关系、map和其他内容。所以这两部分的代码都是“复制粘贴”一样的。
这次作业从算法上来讲（几个复杂的规则检查），还是有一些挑战的。我使用了几个DFS搜索算法，基本和这个类似。其实这块如果有时间的话完全可以做成工厂模式。
四个单元中架构设计及OO方法理解的演进
回顾几个单元写的作业，真的明显感觉到自己成长了不少。不管是对语法原则的使用、设计架构的理解，都与最开始的时候上升了不只一个档次。
分析这11次作业，我发现自己都是在尝试“还原真实场景”，这个说法在表达式、电梯、UML作业中能非常明显地感受到。每一次我都是老老实实地区“恢复”人脑的思维过程。这可能也导致了我的性能分从来不高。
-
第一单元 表达式求导
这时候刚刚接触Java编程，对继承和接口等内容的理解还不是很充分，所以程序写起来有些费劲。尤其是最后一次作业，作为一个“由于自己觉得自己不太会用接口而没有用的”人，真是瑟瑟瑟发抖。但是那次作业，还是很有收获的，比如学会了将对象进行拆分，划分成不同的类；架构上可以整体地进行分析，而不停留在算法阶段……
还有就是浅拷贝和深拷贝的问题，由于我自己“嵌套”定义类，导致这个问题疯狂出现。看到了一句话，“每一层都是浅拷贝那最后就是深拷贝”。自己歪打正着最后弄对了。我在这方面还是很欠缺理解。
顶层类深拷贝代码 当时觉得8个类太疯狂了
还可以提升的地方：
- 对sin、cos等使用工厂模式；
- 对于每一个方法，明确方法的目的（避免现在这样一个方法60行的情况）；
- 别把东西传来传去的，空间复杂度太高了；
- 本应作为类存在的对象被当作了属性（Key什么的我固定保存了系数，实际上应该将sin和x拆开），缺少面向对象思维；
- 不会使用equals和toString，导致代码很鸡肋。
-
第二单元 电梯
多线程部分我感觉到现在还对线程安全问题还缺乏理解……我有好多地方都直接sychronize了，并且还在公测时遇到了严重的线程安全问题。我还使用了一些“结束信号”当作信号枪使用。
我在架构上使用了楼层，将楼层作为共享单元，等于调度器和电梯之间没有什么太大的关联，电梯自己还有许多功能。这样做我认为能在一定程度上减弱线程冲突导致的问题。这回对于类的划分其实很标准，所以我自认为自己写的还行。
现在想起第三次的作业，对于每部电梯有不同的需求，当时应该使用继承的方法去写，这样或许能在性能上有所优化。
还可以提升的地方：
- 在架构上，使用观察者模式；
- 对于线程安全不要一股脑sychronized；
- SOLID设计原则，对于开闭原则理解不到位。
-
第三单元 JML
这个单元的作业给我感触很深。JML规格让我对于工程化开发中的代码分工与架构抽象有了新的认识。我更好地理解了架构的意义。架构师是不用关心方法实现的，仅仅设计每一段代码的规格。同时，这样也保证能够更加方便地对代码进行测试。纵观前两单元的作业，我的程序在这方面做的很不好。
除了有关于规格的撰写，这一单元还对数据结构和算法有进一步要求。在这一点上我做的不是很好，因为从整体上来讲，我的程序就是一个“平面”，即类于类之间没有基本联系，只是传一些数据而已。并且，最后一次作业中的各种带权图算法，其实都可以用一个函数来解决，所以当时应该构造工厂模式。
可以提升的地方：
- 架构不够好，很混乱；
- 类中存储过多属性，应该分别创建映射仓库；
- 此单元代码好像没有体现出OO的本质，对于“对象”的观念不是很清晰。
-
第四单元 UML
架构上是“树形”的结构，我在前文有所提及，所以这里不再赘述。
可以提升的地方：
- 类之间关系清晰，但是内部很混乱；
- 建立了各种映射关系，很容易出错。
四个单元中测试理解与实践的演进
最开始时，测试在我心中还是“随机测试”的方式，即随便输入一些数据，自己计算结果并比对。随着作业次数的增多，我了解到了“白盒测试”和“黑盒测试”，并逐渐应用于实践之中。我会先进行白盒测试，对于某一些方法进行JMLUnit的白盒测试，之后进行压力测试、以及大数据随机测试
-
第一单元 表达式求导
此单元我还是不会很测试，大概只以枚举法测了一下很基本的东西，并结合各种内容构造复杂数据。
但是这样会导致漏掉许多错误场景，比如我一直没有认识到的sin(x)+(x)，我的正则表达式会导致WF。
-
第二单元 电梯
这个单元我已经使用了“黑盒测试”和“白盒测试”，但是还没有像是三单元中那样分别对每个方法进行测试。我写了自己的评测机，会自动生成测试样例，所以测试还是挺充分的。但是第三次作业中由于评测机写的不是很充分，导致翻车事件。
自己写脚本的过程还是很开心的~
-
第三单元 JML
在汲取了上一单元的翻车教训之后，我这次算是真正的测试充分了。我不仅对每一个方法进行测试，还采用了“交换语句”的方式。事实证明这样是明智的，我确实发现了有些很深的bug。
这次我也生成了一些随机数据，保证能够测试到各种情况。但是这次的数据还不能完全是随机的，所以还是有点难写！
我本着“测试是为了debug”的原则，构建了许多比较小的测试样例。
-
第四单元 UML
说实话，这一单元的测试我有一点抓瞎。我不是一个很细致的人，所以导致对拍的时候别人经常能发现我想不到的测试点（菱形接口等）。感谢大家！所以我深深明白了测试不能单打独斗的道理。
这一单元我主要采用了“特殊测试”+“随机测试”的方式，构造让我想不到的场景，检验正确性。
从枚举法到最后的有条有理地“生成”测试样例；从随机测试到最后重点测试，我自认为对于工程化测试有了一点理解。而且，一定要Group Test！陷于自己的惯性思维太可怕了！
课程收获
-
代码方面
- 初步了解了“对象”的思维方式。虽然还是会有对一个类“大杂烩”的情况，但每次我都尝试去解耦、精简方法。
- 有了一定的架构能力，拿到题目的第一反应是“如何设计”而不是“如何算法”。还存在的一个问题是架构经常产生“头重脚轻”的情况，最后一层负责一切计算而上层起不到作用。
- 学习了许多设计模式并去应用。不过有时候由于代码过于“女娲补天”，设计模式被摒弃了，这一点很不好。
- 多线程编程时去思考冲突问题。回顾二单元的几个sychronized方法，我发现这一点还有待提高。
-
测试与Debug方面
- 使用JML进行测试，分析“边缘”数据构造测试集。每次都从整体上把握程序的架构，分析出深层次BUG（比如上一单元总结中提到的只有特定运行顺序才会出现的bug）。
- 每次尝试自己写评测机，工作量有时候有些大但是既能深刻研究指导书，又其乐无穷。
- 学会了不printf的debug方法(O_O)/，用电脑而不是使用人脑来调试。但是对于多线程场景调试能力还不是很好。
- 帮助同学进行debug也能受益匪浅！
-
心态方面
- 深入贯彻落实不到最后一刻不放弃的革命思想，在最后一小时发现bug还敢再交几次。
- 阅读别人程序时越来越不容易崩溃，认真学习他人对于架构的设计。
为什么我代码量1200他只有800？？？
这学期的课程不算多也不算少，OO和OS占用了绝大多数的时间。同时，这两门硬件基础和编程基础的课程在我心中形成了强烈的对比，让我明白了这两门学科是什么，也有了自己的选择。相比于硬件，我发现我更喜欢OO。每一次作业我都能思考上一晚上，每次都考虑自己的收获而不是分数……感谢OO让我对未来的代码生活充满了憧憬！
课程改进建议
- 每次上机之前，希望早点发布上机内容的指导书，这样还能有所准备。真的被前几次上机折磨的够呛哈哈哈QAQ
- 希望形成“小组”的方式进行测试学习和架构学习，这样能更好地向优秀同学借鉴
- 每次作业公布一下下一次的“拓展需求”，这样能有所准备
超喜欢OO课程和课程组！希望OO越来越好！