OO第四次博客作业

架构设计

总结本单元三次作业的架构设计。

第十三次作业

实现类图的读入和分析。要分析类图，自然就要实现“类”这个对象，以及与之相关联的对象（属性，方法）。而接口和类基本等价，于是设置类似 ClassOrInterface 的接口（为省事直接使用了 boolean 变量 isInterface 进行区分），再设置属性类 Attribute ，方法类 Operation。

理解了类图相关知识后，实现起来就是时间问题了。根据元素之间相互依赖的关系分三批次读入类图元素，进而进行查询。所有量都有独自的 id ，按 id 为 key 存几个 HashMap 即可方便地完成本次作业。但需要注意的是，有些输出的内容可重复，故需要合理地运用 ArrayList 和 HashMap 。

第十四次作业

实现状态图和顺序图的读入和分析。先看类图，由于只存在 State（包括初始状态，普通状态和结束状态）和 transition ，直接类比于图的点和边，存到一个类似 Graph 类的 StateMachine 类中；顺序图也类似，由于只存在 LifeLine 和 Interaction 两部分，故存入单独新类中。

对于状态图和顺序图的读入，同样通过对模型元素分批次读入进行，且分三大批次分别遍历模型元素处理类图、状态图和顺序图。这里需要注意程序的鲁棒性，否则在判断 parentId 并不对应一个真实元素时需要特判（顺序图和类图共享某一个 Uml 元素）。

第十五次作业

添加异常情况的判断，由于并不存在多继承的情况，沿袭上次作业架构（如果存在则需要更新“类”类中父节点为 ArrayList ），根据题目要求细心暴力 dfs 或预处理出即可。

这里最开始我没搞懂 UmlAssociation 以及关联关系的实际含义，导致中测的时候 WA 了一次。以下内容复制自当时发的讨论区解答：

UmlAssociation 在代码中即为，被关联类 B 以类属性的形式出现在关联类 A 中，或关联类 A 引用了一个类型为被关联类 B 的全局变量。关联包括单向、双向、自关联，分别举例如下：

单向关联

class A {
    B b;
}

双向关联

class A {
    B b;
}
class B {
    A a;
};

自关联

class A {
    A a;
};

指导书：R001：针对下面给定的模型元素容器，不能含有重名的成员(UML002)

值得注意的是，Association 无论在哪个类下，关联对端的名字才是本类中类属性的名字。

因此只需要对某个类的关联对端和属性的名字进行联合判重即可。

架构总结

总结自己在四个单元中架构设计及OO方法理解的演进。

从一开始的暴力面向过程逐渐转向有一定面向对象思想的编程模式。

第一单元多项式求导中，我基本是直接使用了面向过程编程中的编程套路，分为多项式、项分别进行处理，划分的类也只是因为“需要认为那是个对象”或“把它分类处理更容易实现”而进行实现的。表达式类内部暴力的对字符串进行处理，几个函数也都是为符合 checkstyle 不超过函数限制行数而创建的。

第二单元的电梯调度中，就明显感受到面向对象模式的重要性了。每一个对象都各司其职，电梯就干电梯的事，调度器就分别调度人和电梯，等等。我将电梯、电梯调度器、总调度器分别署类，各司其职，其中为了测试哪种方法更优还写了多个不同的调度器分别运行进行对拍而不产生差错，可谓这时候我的面向对象架构已经较为完善了。

第三第四单元做了些啥？

测试总结

总结自己在四个单元中测试理解与实践的演进。

在三四单元中，也是在学完 Ruby on Rails 中测试驱动开发的做法，我逐渐学会使用了 JUnit 进行单元测试，并且应用到了迭代开发的测试中，这就是四个单元中的所有演进。关于测试驱动开发，我认为在产品迭代的过程中尤为重要，每次重构或增删代码的时候，有了之前做的测试，方能够更放心大胆地进行开发与重构。

然后其余普通的测试方法还是和前几次博客总结里一样，分为两部分：

1. 手动构造边界数据；
2. 对拍测试（包括和标程对拍或测试答案正确性或和同学对拍）。

其实我们的程序主要还是做架构，架构做好了，才有更好的扩展性、良好的鲁棒性和更低的出错概率，而用测试帮助我们验证边界情况和没有预想到的情况。所以测试要在手动数据做好充分的边界情况判断前提下，尽量多的使用各种方案（其实也是一种 corner case ）产生的各种随机数据。

课程收获

总结自己的课程收获。

第一单元帮我们构建了整一个 OO 体系的思想，让我们深刻地理解到将一个大任务分割成一些对象，并通过继承、接口等方式构建共同点、分而治之的巧妙思想；第二单元搭建起了整一个多线程程序的框架，让我们理解并发执行多个线程的思想和实现过程，并让我们切身实际体验多线程中锁的重要性以及死锁的预防方式。第三单元让我们了解了契约式编程的思想，并使用 JML 进行开发。第四单元让我们了解了 UML 类图，顺序图和状态图的实质与分析。

整体来看，课程收获主要在前两个单元，尤其是第二个单元，无论在难度方面还是内容方面都非常优秀、丰富。通过这四个单元，我收获到了 java 语言的更深一步学习和面向对象模式的内涵理解。

改进建议

立足于自己的体会给课程提三个具体改进建议。

1. 我认为第三单元 JML 完全可以删掉，理由有：
   1. JML 并不是一个成熟的、适应当下工程需求的工具；
   2. 没有一个合适、能充分验证、完备的 JML 工程体系， JML 工具链的正确性保证也没有得到验证，也很难保证助教对于 JML 书写的绝对正确性，作业存在一定问题（不是说助教有问题，就是老师本身来写也会出错）；
   3. 契约式编程可以列入建议学习，就像在第一二单元中我们很多同学都自学了很多种编程方式如防御式编程等一样（我没实习过不知道企业是怎么给分配任务的，还请老师斟酌）。
2. 我认为第四单元 UML 完全可以变成两次作业。本来就实现难度不高（但麻烦）的事情分成三次作业过于水，且考虑到对于期末考试考期的冲突，可以适当删掉一些麻烦的内容变成两次作业（早死早超生）。
3. 我认为某几次实验内容需要一定改进。别人冗长还有 bug 的代码真的没人想看，而且但凡给别人神秘代码找过 bug 的人都会 ptsd ，尤其是没注释或没逻辑的。但其实由于其本身就在第三单元，所以明年 JML 如果还有的话，建议修改。
4. （提四个建议不要紧吧）第二单元一定要先讲 Lock 和 Condition ，后讲 synchronized ，这会让我们我们理解所需时间巨额减少。或者说把这单元往后放放，等 OS 讲完类似的相关内容后再做作业也会略微轻松一些。
5. （那五个也可以吧）实验课最好给个参考答案，而不是以“给你答案了助教怎么给你捞分”这种显然的借口搪塞。不知道答案，实验课基本白过两小时。

学习体会

谈一谈线上学习oo课程的体会。

OO 这种课程在线上线下还是几乎差不多的。就记着当时研讨课的时候一片寂静就自己在瞎说的时候有一种很空虚的感觉，可能老师在对着屏幕录播的时候也是这种感觉吧，少了一些分享的激情和感觉。其他的由于本身就在线上进行下发、测试等等，基本没有什么影响。

很荣幸能够成为今日无论是评测还是内容都较为完善的 OO 课程的受益者之一，这是数届老师和助教的辛勤努力结成的硕果。今年的 OO 给我们以丰富的面向对象知识和绝佳的测试体验，我也满怀期待和信心，明年的 OO 能够让下一届的学生们发出如此赞叹，北航的 OO 课程也将逐渐让一个个六系学子们在走出校门前，成为一个具有全面面向对象知识和技术的程序员。