OO第四单元总结与课程总结

OO第四单元总结与课程总结

一.本单元两次作业的架构设计

第一次作业

第一次作业是要根据接口解析出的UML类图元素信息进行对类图的查询，关键在于对给出信息的存储与使用。我的做法是建立一个UML类，存储UMLClass和UMLInterface的操作，属性，父类，实现的接口等，同时实现查询操作所要求的方法。由于操作包含参数及返回类型，所以再建立一个OperaPara类用于处理操作层面的查询。借助parent元素总是先出现，在MyUmlInteraction构造器中用for循环将元素存储进Uml和OperaPara。

类图

架构整体没有问题，但是忽略了接口可以多继承而出现bug

第二次作业

第二次作业新增状态图和顺序图的查询和有效性检查，图的处理方法与类图类似，建立StateMachine类对应StateM类，Collaboration类对应Interaction类，StateM和Interaction分别存储状态图和顺序图的相关信息。有效性检查只针对类图，因此新建一个Precheck类与Uml类相关联，Precheck里实现三个检查方法。

类图

这次架构也没有问题，但是做循环检查的算法有小bug

二.四个单元中架构设计及OO方法理解的演进

第一单元

第一单元做的是对表达式求导输出，那时没有OO的概念，而且对表达式正则判断，拆解，求导，转成字符串输出的操作很面向过程。前两次作业较简单，只需用一个Item类存项即可，最后一次作业难度突然加大，需要考虑各种递归，这就不是随便写写就能完成的了，需要设计完整的架构，从表达式到项再到各类因子要仔细规划统筹，虽然很难很麻烦但也让我体会到架构的重要性。

第二单元

这个单元做多线程电梯，体现了OO独到之处。我们在这个单元接触到了设计模式，而电梯作业就可用生产者消费者模式解决，用户请求是生产，电梯是消费，控制器作为托盘，每个模块只实现相应功能，符合OO思想。我也在这个单元更深刻的感受到了架构的重要性，因为第二次作业没有设计好，实现起来特别困难，勉强完成后bug还层出不穷，所以第三次作业完全重构，采用更简明低耦合的设计，虽然花费大量时间但最后结果很让人满意。

第三单元

第三单元学习了JML，这延伸出了对OO来说十分有效的测试方法，对高内聚低耦合的OO模块做单独具体的特点测试能更方便的发现bug，构造更全面的测试样例。不过遗憾的是这个单元我的架构设计很不好，与其他同学比对时发现采用同样的算法而程序执行却要耗费更多乃至数倍时间，最后由于时间紧张也没能完成重构。

第四单元

这个时候我已经能较轻松的写出一个OO程序了，不用太考虑细节而做出整体的设计。这个单元作业也比较简单，对解析得到的信息做系统的整理处理即可，我也相应设计了一个不错的架构，因此第二次作业扩展完成的很轻松。

三.四个单元中测试理解与实践的演进

​ 第一单元一开始的时候什么都不会，只能硬着头皮一个个的构造自以为容易出bug的样例，后来看了讨论区学会自动生成表达式，又学会写自动对拍器，这对我第一单元的互测有很大帮助，当然也有很多不足，比如大量同质bug。

​ 然后做电梯作业时没有学到什么测试方法，因为即时输入太难了。。不过第三单元接触了Junit后又有了新的测试手段，对照jml规范对单个模块构造全面样例做特异性测试，这使我们在互测时不再要阅读七个人大量代码，还能更准确有目的性的找bug。当然junit不止可以用于互测，我在第四单元作业完成后也用junit进行了一些测试，找到了几个考虑不周的空指针bug。

四.课程收获

面向对象的思维：将世界万物对象化更符合人类的认知，将程序代码也对象化则能更方便编程者和使用者，写程序时要关注各个组件的细节，用程序时只要注意接口，大大提升扩展性

设计架构的能力：几个单元的作业让我对架构有了全新的认识，好的架构虽然设计麻烦，但能为之后带来巨大受益，还能对程序性能有提升

Java编程的能力：这学期用java写了很多很多代码，无论时编程还是debug的能力无疑都得到了巨大提升

搜索学习：课程上的内容偏于理论，再实际实践的时候会遇到千奇百怪的问题，这时就要动用强大的搜索引擎解决一个个实际问题，这也另外受益匪浅

五.改进建议

1.理论课的学习感觉作用不大，OO课程重心在课下作业，增加理论课与课后作业联系结合会更好

2.对于卡CPU时间的作业希望能提供评测机模拟

3.实验课作用也不大，做完实验没有后续讲解，不知道完成的怎么样也没学到什么东西