OO终章——第四单元总结
OO终章——第四单元总结
终于终于，曾经觉得不可战胜的OO迎来了结束。回顾这一学期以来，学习OO的过程可能就是一个痛并快乐着的历程。
PART1 第四单元三次作业架构
UML单元个人认为其实第一单元是最难的。从0到1，从无到有总是一个比较困难的过程。
第一次作业
目标：完成对类图的查询
设计想法：这部分内容其实可以在一个类中实现，这样实现起来比较容易功能集中，但是不符合面向对象的思想。虽然第一单元的设计比较复杂，但是在后续作业的迭代过程中就相对简单了。
analysis：对输入的不同类型的element进行分类，建立之间的关系
MyClass、MyInterface实现MyModel，内部对各自的方法、属性和关系建立OperationManager、AttributeManager以及AssociationManager，OperationManager内部还存在UmlParameter，故为UmlParamater的查询加入VisibilityMap和MyOperation
点评：个人感觉本次分的类还有有点过多了，建立这个框架所需时间比较长。不过也是一次面向对象思路的友好尝试。后面迭代起来还是很容易的。
第二次作业
目标：加入对状态图和顺序图的查询
设计想法：鉴于第一作业分类过细的小缺点，第二次作业新加入的类分类更加清晰。
MyUml*Interaction：实现整体功能，对不同种类图的查询功能
MyStateMachine、MyUmlInteraction：单个顺序图、状态图对象
MyLifeLine、MyState：更细化的对象，顺序图主要由生命线和消息组成，MyLifeLine实现对象的集合，使得顺序图包括MyLifeLine即可，MyState同理
第三次作业
目标：格式检查
设计思想：R001-R006都是对类图的格式检查，R007-R008对状态图格式检查。由于我的设计上文分类已经比较细致，所以直接在对应的MyUml*Interaction加入对应的检查即可。
重点讲一下难点的思路：
R002：循环继承：只会发生在类与类、接口与接口的继承关系，分别找即可。
类与类:如果存在父亲与自己一样了，说明存在循环继承；
接口与接口:借鉴JML单元，我当时是用的DFS思路，即判断接口与接口的父类之间存不存在父类到子类接口的通路，如果存在，记录上每条存在的路径。
R003、R004都可以利用BFS的思路解决。
PART2 四个单元中架构设计及OO方法理解的演进
第一单元
第一次作业可以说我很有勇气尝试面向对象的思想，建立了很多类。基本符合课程组给出的思想，对操作、函数等分别建立对象。
第二单元
第二单元电梯作业建立输入线程Input和电梯线程Elevator，通过Controller核心调度。
第三单元
JML的作业框架基本都已经建好了。在第三单元的作业中可以看到，我并没有新建其它类，只是实现了对应接口。
第四单元
请见第一部分内容
OO方法理解的演进
有一点我认为自己在训练过程中做得比较好的是，我每次都在尝试着去用面向对象的思想解决问题，没有出现过一个类解决问题的情况。
第一单元的时候我认为只要俺多建类，俺就是有对象！结果就是因为建的类太多，导致出错的可能性变大了，第一单元二三次作业都爆炸。
第二单元的时候我已经大概了解了面向对象的目的和应用，电梯是我们日常生活中一个比较常见的例子。我认为这单元虽然难，但是很好的让我立即了面向对象的思想。把OO日常抽象的理论，放到现实生活中一个很常见的例子。让我理解到，电梯这个实物，他就是个对象，可以用类去封装；乘客自己是个对象，用类去封装；包括调度器也是个对象，用类去封装等等。
第三单元更多的在于对于规格的理解与实现，设计的发挥空间比较小。
第四单元采用UML的解析例子，把UML各个部分封装成对象。一个很大的提升就是第一单元一旦面临很多类俺就bug不断，第四单元可以比较轻松地盘桓于不同地类了。
PART3 四个单元中测试理解与实践的演进
测试非常重要，由于我这个人很多时候比较马虎，很容易出现简单的bug，覆盖性测试就更加重要。我基本每个单元都会出现因为测试不周导致出现错误的情况。
测试分为
黑箱测试->构造自动测试用例，和别人对拍
针对性测试->针对自己核心代码类进行测试
单元测试->对单个类的功能进行测试
但是比测试更加重要的是，不要引入Bug。我借了我的大佬朋友的代码对拍时，感觉到他是在用很简单的方式完成功能，而我却用了很复杂的逻辑去做。所以人家写的又快又正确，而我写的又慢又一堆bug。这种代码能力确实还是需要锻炼的，要写代码和测试两手并进，都要不断强化才可以更好地保证程序的鲁棒性。
PART4 课程收获
- 从面向过程的思维中出走，投入对象的怀抱；从认为建立一堆类就是面向对象，到真正寻找“真爱”对象
- bug就在那里，可你却常常视而不见。当测试出现Bug，再去找Bug，会感觉自己简直是智障；但是测试的时候却常常感觉自己的程序真是无坚不摧。覆盖性测试很重要！不够很多时候自己再读一读自己的程序可能比随机测试效果来的更好
- 知识：多线程、JML、UML等，JML工具链使用等等
- 心理素质（×打不死的小强 不放弃就会有希望
PART5 三个具体的改进建议
1.研讨课相关：研讨课的形式非常好，但是个人感觉有时候对我的帮助其实不是很大，包括我认识的一些同学积极性也不是很高。我认为主要原因是讲解的同学在分享自己的思路或者是测试工具等等，但是讲解的同学和听众的知识储备并不是一样的。讲解的同学大多学得比较好，并且认真准备了要讲解的内容；而听众们可能对讲解同学所讲的内容并不熟悉，（举个栗子：讲解同学在讲自己搭建的评测机，但是这是他可能尝试很多次从而得到的项目，但是听众们可能从来没有搭建过、搭建过但思路不同或者甚至就根本不打算搭建了）仅仅听一遍除了感叹“啊，大佬就是大佬”之外，并无实质性的收获。
以下是我认为可能的改进方案：
讲解内容：可以多关注一些大家都可以听懂或有用的内容，比如工具链的使用等等，但是对于比较高阶的使用，比如自动测评机等等可以略讲，或者专门开一个会议，有需要的同学参会进行讨论，可能层次相近的同学间更有思路交锋的效果。
2.实验课相关：不知道可不可能每周实验课结束公布一下结果，不知道自己做得对不对。
3.作业相关：猜测OO作业也是逐年迭代难度嗷（还好我结课了(●ˇ∀ˇ●)
PART6 线上学习oo课程的体会
感觉线下学习OO课程挺好的，可以反复学习课程。而且我本人比较容易焦虑，在校如果每周都面对OO项目的打压，可能会感觉非常紧张，但是在家的环境很好环节了我的焦虑。很多次OO刷页直接在床上写代码，感觉还是非常踏实的。唯一比较遗憾的就是，没能看到老师和助教的面容（爆照吧o(￣▽￣)ブ
