OO第四单元博客作业
第四单元两次作业的架构设计
这两次作业仍然是实现官方提供的接口，最大的收获便是通过自己写代码解析UML语言熟悉了UML语法
第一次UML类图解析作业
第一次作业要求我们实现一个类来完成对类图各个讯息查询的功能。
由于输入的各个umlelement都是通过parent等讯息来储存元素之间的从属关系，而查询指令大多都是要查询某一类的相关讯息，因此我选择了自己封装一个MyUmlClass类，存储与这个类相关的讯息，包括属性、父类、关联元素、操作等，同样的，对Interface、Operation这种包含有其他元素的类也进行了封装。在构建完各个元素之间的从属关系之后，查询就简单了许多，直接枚举需要查询的元素即可。
结构图如下：
耦合如下：
在做完第二次作业后反思，觉得自己在封装一个类的关联元素时拓展性做的不够好，应该存入associationend而不是与类关联的那个元素，因为end中也存有和这个类有关的讯息，如果直接存关联元素，提取end中的信息就需要重新遍历关联关系，而存入end，不仅可以使得信息完整，而且通过reference查询关联的元素也并不麻烦。
第二次UML类图解析作业
第二次作业要求我们加入对顺序图和状态图的解析，以及检查类图是否符合正确的规则。
第一次作业相关的指令我使用继承上一次的作业解决。
本次作业是oo的最后一次作业，考虑到进入烤漆，课程组也帮我们在数据上做了许多简化，对顺序图和状态图讯息的查询都是简单的遍历元素即可完成，考虑到没有下次作业也就偷懒没有进行什么设计直接暴力枚举了。对于类图的正确性检查，因为一开始指导书并未说明，会不会出现类多继承，接口继承类等非法情况出现在数据中，我采用了别的同学的一个很好的想法，把类和接口都一视同仁当作点，按照实现和继承关系建边，构造有向图，然后就是使用dfs来判断是否有环或重复继承。
结构图如下：
耦合如下：
四个单元中架构设计及OO方法理解的演进
-
OO第一单元有三次作业
从普通的多项式求导，到带有幂函数、三角函数的表达式求导，再进化到加上嵌套函数的表达式求导。
- 第一次：将单项式和多项式抽象成两个类
- 第二次：多项式使用ArrayList存储单项式，单项式使用ArrayList存储因子，再额外使用Biginterger存储单项式的系数，各个因子类共同抽象出一个父类包含一个index指数属性。多项式求导调用单项式求导再相加，单项式求导调用因子求导先相乘再相加。
- 第三次：在原有类的基础上增加了poly型因子并将三角函数因子改为嵌套型因子，还把输入和输出抽象成单独的类
-
OO第二单元共三次作业
需要完成的任务依次为单部多线程傻瓜调度（FAFS）电梯的模拟，单部多线程可捎带调度（ALS）电梯的模拟，多部多线程智能（SS）调度电梯的模拟。
- 第一次：使用生产者消费者模型
- 第二次：生产者消费者模型
- 第三次：生产者消费者模型
-
OO第三单元共三次作业，需要完成的任务大概是统计图的简单信息，图的连通及路径信息，仿地铁线的无向图带权最短路信息。
- 第一次：只有MyPath和MyPathContainer
- 第二次：只有MyPath和MyPathContainer
- 第三次：只有MyPath和MyGraph
-
OO第四单元共两次作业，需要完成的任务为统计uml类图信息，统计uml顺序图、状态图信息及类图正确性检查。
- 第一次：封装一个MyUmlClass类，存储与这个类相关的讯息，包括属性、父类、关联元素、操作等，同样的，对Interface、Operation这种包含有其他元素的类也进行了封装。
- 第二次：把类和接口都一视同仁当作点，按照实现和继承关系建边，构造有向图，然后就是使用dfs来判断是否有环或重复继承。
四个单元中测试理解与实践的演进
我的OO测试经历了手动构造数据测试，到搭建评测机测试，再到评测机junit单元测试辅助测试。
通过惨痛的bug经历懂得了测试以及覆盖性测试的重要性，以及如何做到全面覆盖的测试，也学会了写生成数据的脚本、写spcjudge脚本、写对拍程序等
课程收获
一学期的OO课程，让我感觉收获颇丰，入门了一门新的编程语言java，了解了面向对象的设计方法，初步认识到了到底什么是一个类，学会了如何使用继承、抽象类、多态等写法，学习到了许多设计模式，但实践的并不多只有工厂方法、消费者生产者。学到了新的编程方法：多线程编程，学会了简单控制线程互斥与同步。还了解到了jml这一规格化语言，以及junit单元测试这种逐个方法测试的测试方法，最后还学洗了使用uml类图来构建工程的框架。工程能力毋庸置疑的也得到了很大的提升
给课程提建议
- 作业梯度方面。作业难度梯度没有循序渐进，而是“跌宕起伏”。第一次作业时刚刚接触java语言以及面向对象的概念，我觉得更适合那种官方提供一个代码包，然后让同学来继承接口实现代码的作业，而且当时os也不难，大家都有时间、有精力而且还保持着对oo的浓厚兴趣，可以让大家阅读官方给的代码来深刻理解面向对象，理解如何抽象一个类等，或者每次作业后提供官方标程，否则就是全凭理论知识自己摸索，效果并不好。
- 互测方面。就算代码风格通过checkstyle统一规范，但看着没有注释、没有readme、完全不知道什么思路的代码还是让人头疼，在之后OS难度飙升的情况下花大量的时间去学习阅读别人的代码的人确实少之又少（可能我认识的人都比较懒）。找bug也真的就是锻炼大家搞评测机的能力吧，而且有些代码中很明显的线程方面的bug只靠单次评测可能无法测出，建议多次评测，或者开放人工审核多线程bug窗口，以及规定必须写一个比较完整的readme文件来阐述自己代码的思路（注释就算了，毕竟程序员都不喜欢写注释）。
- 上机实验方面。建议调整上机实验内容，不要上午学，下午考，留给我们的学习时间很少，而且也只有一次提供了预习文档。