目录
前言
一、第四单元两次架构设计
二、架构设计及OO方法理解的演进
三、测试理解与实践的演进
四、课程收获
五、改进建议
前言
持续了17周的OO终于走向了尾声，想想寒假的时候连类都不知道是什么，到现在一学期下来收获真的是挺大的。
前排感谢mole群的群友们！
一开始还有很多同学喷oo，或许是由于刚开学的压力，由于往届传来的oo口碑。但可以看到，在老师和助教的努力下，这学期有了诸多重大的改进，随着课程的进展，好评越来越多。就我个人而言，这学期强测+互测屋的制度让我觉得基本消除了公平性问题，并且游戏感强，很能激发学oo的兴趣，与这学期的另一门课程形成了鲜明的对比；讨论区很活跃，但废话又很少，与这学期的另一门课程形成了鲜明的对比。总之，感谢老师和助教们的辛勤付出，总体上看，这学期是一次彻底转变口评的改革。
一、第四单元两次架构设计
（1） 为了尽量让代码逻辑清晰，且方便调试，本次作业我单独开设了AttributeManager, OperationManger, AssociationManager, MyInterfaceManager几个类，其实例作为自定义类MyClass的成员变量来分别管理属性、操作、关联与接口。MyClassManager在更高层次对MyClass进行统一化管理，由于对于接口相关的需求相对类来说是独立的，同样设一个InterfaceManager类对接口之间的继承关系进行统一化管理。
为了降低函数之间的耦合，对于每一个种类的UMLElement设置一个专门的函数负责它的初始化，如下图所示。
（2） 为了尽量满足open-close原则，第二次作业我基本没有改动第一次作业的代码，只是将其打在一个包里。对于新扩展的功能，即解析时序图，解析状态图与合法性检测，分别打包来管理。这次作业除了理解指导书意图外的唯一的难点在于合法性检查中的R003，也就是对重复继承的precheck。我最后的方法核心思路是这样：在第一次作业中初始化过后每个自定义类都保存了它继承的所有类和实现的所有接口，如果存在多继承，那么它实现的接口至少有一个有至少两个被继承或实现关系。
二、架构设计及OO方法理解的演进
（1）第一单元的前两次作业基本完全面向过程，在面对第三次作业这样复杂的需求时，只能完全重构，不过因此我也第一次尝试了继承，多态（接口和抽象类）的使用，发现架构真的是清晰很多，多态的运用也简化了编码的难度。
（2）第二单元的作业体现的主要是架构的设计，而关键的架构设计主要在第二次作业，因为第三次作业基本可以完全沿用第二次作业的架构。最重要的问题就是电梯和调度器之间的职责划分和他们之间的协作关系。这一单元我感受到了设计对于编码的重要性，尤其是多线程问题。
（3）第三单元作业的主体架构是官方提供好的，再之后粗浅的了解了一些设计模式后，发现可以用策略模式来比较不同最短路径算法的性能，这样统一化的管理不但满足开闭原则，为了各个策略接口统一，也可能避免一些潜在的错误。
（4）第四单元我第一次尝试了打包管理各个类，感觉确实会清新很多，这次第一次作业的设计我也刻意遵守了单一职责原则，关联，继承，属性，操作等交给特定的类去管理；在第二次作业的功能扩展中我也刻意遵守了开放封闭原则，尽量在不修改第一次作业代码的基础上扩展功能，尽管牺牲了一些性能。
三、测试理解与实践的演进
（1）从测试模式角度：
第一单元：
数据生成器：利用python的Xeger包
正确性检查：由于不同人的输出格式很可能不同，因此只能接触单独的正确性检测脚本来实现，这里选用了matlab脚本
WF检查：与好友对拍
第二单元：
数据生成器：这一单元的数据生成器是最好写的，指令与指令间没有逻辑，也不需要外部引用其它包
正确性检查：这一单元的正确性检查脚本是最难写的，因为没有现成的工具可以利用，只能手写。
第三、四单元：
这两单元的正确输出都一样，因此只需要对拍即可，难点在于数据生成器。
（2）从写评测机角度：
写评测机是学OO一大乐趣，第一个单元写出来的评测脚本基本半自动半手动，由于用的都是绝对路径因此没有可移植性，经过了几周的不断修改，到第二单元最后已经实现了这些功能：
- 兼容windows与linux，因为第二单元的测评等的时间太长了就挂服务器上跑了
- 不依赖于路径，放在哪都能跑
- 实现了弹夹的自动装配，弹夹的增删不影响评测机的代码
- 实现了玩家的自动注册，玩家的增添不影响评测机的代码
- 实现了正确性检查脚本的可替换，不同的作业只需要改动checker类的方法即可
- 实现了自动编译代码
- 因此第三四单元的作业没有改动过评测机的代码，每次测试要做的就是装配弹夹
四、课程收获
相比其它课程而言，OO显然是这学期收获最大的一门课，主要体现在以下几点：
（1）编码能力的提升：
这点对所有认真写完11次编程作业的同学都是毋庸置疑的，每个单元的非第一次作业难度都不小，无论是写还是测试都没少肝。
（2）对架构设计的认识：
架构的力量主要表现在工程量较大的科目，比如上学期的计组，不过那是一门硬件课。OO是我接触的第一门软件方面代码量较大吃的科目。第一单元的前两次作业写得都比较面向过程，但从第三次作业开始，如果没有一个好的架构是很难写出易于调试与优化的程序的。“这次作业要设置几个类？他们各自要实现怎样的功能，对外要提供怎样的使用接口？类与类之间的协作关系是怎样的？这么设计是否有更好的可扩展性？”这些问题的思考变成了每次作业耗费时间最长的环节，不过当在草纸上想清楚这些问题后，之后编码就轻松很多了。
（3）对测试的实践：
虽然这部分内容在之前已经说过了，不过鉴于写评测机和对其不断优化的过程真的是带来了很多乐趣与小小的成就感，还是要将其作为课程收获单独列为一点。几个单元下来，摸了一些matlab，windows和linux的命令行，java编译的各种命令行操作等等，python的使用也比之前熟练了。
（4）向身边的同学学习：
整个过程中在与好友们的交流中也学到了很多，比如写数据生成器的思路，架构设计上的骚操作等等；研讨课也经常能从大佬得到启发；还有讨论区，感觉第三单元第三次作业讨论区的处理方法真的是太太太太巧妙了，既容易实现性能还极强。
五、改进建议
说实话，一开始想吐槽的一些点基本都在课程的进展中已经被改进了。比如一开始OO实验上午讲课下午就考试的问题，之后基本会提前通知实验内容并下发预习材料；然后课上实验一开始15min的冷冻期也取消了。剩下的建议如下：
（1）关于作业内容：
a.我们有的
从结果的角度分析，第一单元的作业起到了测试入门的作用，第三次作业是我个人认为所有作业中OO味道最足的一次，封装，继承，多态都有所体现，而且架构弱的话很难写出没有bug德程序，也很难优化。第二单元的作用没什么可说的，多线程无可替代。而第三四单元的作业个人感觉完全是各种算法题的杂糅，并且用面向过程的方法反倒性能更高。
b.我们没有的
目前的形式并不会去push同学一定要应用solid原则中的某几条，或者某种设计模式
c.综上，是否有可能将第三或四单元的作业改成类似于“协作开发”的形式，每个人的工作量以类为单位，要求其特定类的设计要满足特定功能，并且不要有危险的行为，比如某个public方法会抛出关键的实例对象等。
或者类似的其它做法，设置一个可以典型反应solid原则与某些设计模式的单元，先由同学独立完成一次作业，下一次作业的框架由老师或助教搭好（这个框架要体现solid原则中的某些特点或设计模式中的某些模式），提供一些类的设计说明书让我们去以填空的形式完成，让我们从对比的过程中认识到这些原则及模式的好处。单纯的助教发实例代码或者同学在研讨课上讲其实大多数人很难理解。
（2）关于互测与强测分数比例
建议提高互测的分数比例，主要基于以下两个依据：
- 由于互测占的比重过低，到后期互测的参与度明显下降，这不利于下一届的口评导向，比如会有人和学弟说“互测基本没啥影响，把这时间留着干点别的什么不好”；同时也不利于大家在互测中借别人之手发现自己的bug，违背了开设互测的初衷。
- 互测的bug和强测的bug没有本质区别，只是写数据的人侧重点不一样，很多逃过强测的人仍然会有很明显的bug。
（3）关于强测的扩展
无论这部分是否占分，也许可以有一个用A屋中的精品测试数据对所有人再次测试的过程，以便大家发现自己的bug。
（4）关于指导书样例
后两个单元的指导书样例确实有点少，在这种情况下我们就只能通过在讨论区不断问来解惑，并且事实证明很多结果和大多数人的理解不一样。有的时候如果架构为了性能鲁棒性差的话一个小的需求的变更可能都会伤筋动骨，就容易改出bug来。
-----最后的最后，祝oo越来越好！-----
