BUAAOO 第四单元及课程总结
一、第四单元架构设计
第十三次作业
第十三次作业要求解析类图，于是我自己设计了MyClass、MyInterface和MyOperation三个类用以保存相关的信息以及设计相应的查询方法。还有一点就是在构建整个模型的时候对元素的解析是分层次的，我是选择遍历三遍，第一遍读取UmlClass、UmlInterface，第二遍读取UmlAttribute、UmlOperation、UmlAssociation、UmlGeneralization、UmlInterfaceRealization，第三遍读取UmlParameter，这样就不会出现“找不到妈的孤儿了”（除非本来就没有）。
第十四次作业
第十四次作业其实就相当于复制了两次第十三次作业，新增了顺序图和状态图，于是我将第十三次作业MyUmlInteraction的内容转移到了MyUmlClassModelInteraction，然后在MyUmlCollaborationInteraction和MyUmlStateChartInteraction中依次实现接口的功能，MyUmlGeneralInteraction仅用于整合三个实现类中的方法，这样设计的好处就在于第十五次作业增加格式检查的时候直接在MyUmlGeneralInteraction中实现不会超行数，顺序图和状态图的解析也并不困难
第十五次作业
第十五次作业仅增加了格式检查，所以对于架构来说相比于第十四次作业基本没有变化，在实现的时候我采用了不太OO的方法，将三个解析实现类的属性全部复制了一份到MyUmlGeneralInteraction，主要是为了解决某些情况下要同时用到两种图中信息的问题。
二、架构设计及对OO方法理解的演进
第一单元
第一单元的时候对于架构设计是完全陌生的，因此当时费尽心思想要做出一个好架构，第一次作业的架构设计还较为清晰（只有指数和系数，比较简单），后面两次（表达式、项、因子，较为复杂）则采用了比较投巧的架构设计，其实就是只顾着正确性和实现简单而设计的架构，没有考虑性能的优化，算是中规中矩的一次尝试，也为我后面架构的设计打下了一定的基础。第一单元也让我认识到面向对象设计的思想，封装性得以体现。
第二单元
第二单元的架构没有第一单元那么困难，主要是要保证线程的效率和安全性，所以这个单元主要还是考察线程相关的知识。当然，为了保证线程的安全性，一个好的架构设计是非常关键的，我在第五次作业的架构设计中没有把共享对象单独拎出来，在实现的时候就显得非常困惑，在加锁问题上付出了很多时间，但是后面两次作业我是抛弃了第五次作业的架构，将共享对象（等待队列等）单独写成了类，相关的方法也都写在了一起，在加锁的时候就不会忘了或者加错了。
第三单元
第三单元的架构设计就涉及不多了，主要是根据JML写代码，并且整体的架构都已经设计好了，这个单元最关键的就是性能问题，JML只保证了正确性，照着写的话会导致低下的性能，因此容器的选择、算法的设计在这个单元显得十分重要。
第四单元
第四单元主要是对层次化的理解，对UML图中元素的层次化解析相当关键，层次确定了，架构也就清晰了。
三、测试理解与实践
手动测试：一般来说这都是对于某些不太确定的地方构造边缘数据来减少强测中可能出现的BUG
对拍器：我只在第一第三单元实现了对拍器，就是简单的输出文本比较，而对于数据的生成没有非常深入的研究，这导致自动生成的数据往往过于随机没有特别好的作用，因此对于极端情况的测试还是以手动构造数据为主
说实话我并没有投入太多时间在测试上面，我更加偏向于在写代码的时候深思熟虑，先考虑好各种情况，对于某些特殊而用不到的情况（比如if-else中不应该出现的情况）加上错误提示，这样会使得BUG变少以及BUG的定位变得简单。OO这门课的测试，尤其是自动化测试，更多人都是用于互测hack别人的，说实话我还是不太支持这种行为，为了获得这门课的分数而借助于课外的其他内容，这不是促进内卷又是什么。
四、课程收获
面向对象的思想：学会了用“对象”的角度看待事物，从大量庞杂的事物中抽象出一个一个的类，做好封装
java编程语言
一定工程量的代码能力
...
五、课程建议
-
在公测数据上的斟酌：不要出现因为输出少打了几个空格强测30分而前面全过的情况！
-
互测制度：现在的互测完全就是逼同学去写评测机以及构造数据的，这完全违背了课程想要我们阅读他人代码的初衷，而且互测是真的促进内卷。建议取消互测或者改进，这里提供一种思路：课程组放出一些错误代码，让同学们阅读并找到错误并指出具体位置，每人修正代码量有限且总量足以满足同学的修改数量预期（要求有一定量的代码份数），这样同学们大概率不会为了一两份代码而写评测机，而是确确实实地阅读代码。当然，细节之处还可以改进，比如：按错误等级给代码分类，等级越低数量越多等等。（要求课程组的能力足够...）
-