OO第四单元总结

OO第四单元总结

一、第四单元作业总结

本单元主要有两个任务：

1. 对UML类图进行解析。

2. 对顺序图和状态图进行解析。

1.第一次作业架构分析：

作业内容：本次作业通过分析uml图，将各个元素解析出来，将各个元素进行处理，构建一个查询程序，使用特定指令进行查询图内关系

架构设计：本次作业运用了大量的HashMap，目的是将各个元素之间通过索引key查询value。架构中主要使用的算法包含深度优先搜索DFS。

类图如下：

2.第二次作业架构分析：

作业内容：本次作业在第一次作业基础上增加了顺序图和状态图的内容，总体上内容相同，也是通过特定指令查询图内关系。

架构设计：本次作业运用了更大量的HashMap，将各个元素之间通过索引key查询value。架构中主要使用的算法包含深度优先搜索DFS。

类图如下：

3.第四单元教训总结

本次作业存在的主要问题是未能够很好的设计要求类，以至于写的太多太杂，没有很好的分层设计，在checkstyle检查时类超出了500行，费了大量功夫修复代码style。

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

1、第一单元架构设计

本次作业的内容主要是多项式求导，但是因为第一次作业和第二次作业没有很好的设计架构，第三次作业进行了重构，学习了递归下降的方式处理表达式，对作业需求进行一部分一部分的拆解，最终全部化成小问题来解决，这种思想是我在本单元学习中最为深刻的。

2、第二单元架构设计

本次作业主要完成多线程的设计。最重要的学习部分就是调度器的设计，通过单例模式成功实现了多线程之间的交互。将直接提出的需求与实现之间构建一个桥梁，类似于缓冲的设计，这个单元我还可以在性能上面多做优化，本单元的代码的可维护性也比较高，三次作业体现了明显的递进关系，达成了训练的目标。

3、第三单元架构设计

本次作业主要完成JML语言的理解与实现，先写规格后实现是一个很好的代码习惯。本单元主要采用的图搜索方法是Floyd算法，采用了简单的三维数组进行Floyd的计算。作业的难度梯度和代码的设计上有明显的递进关系，本单元完全按照需求的增加而在原有的代码上做少量的增加或删改。本次作业在性能上可以进行大量的优化，主要包含图更新的时机，在查询时如果出现路线的变更再进行图的更新且仅更新一次是我这三次作业性能优化的主要思路。

4、第四单元架构设计

本次作业主要完成UML图的解析以及图内信息的查询。最大的问题就是类设计上出现了超出500行这样没有很好架构的现象，但本次作业运用了大量的HashMap，大量Map的实用让我感受到了java真正的强大。

5、OO方法理解

在本课程中，四个单元的架构都是按照作业要求进行作业设计，但都缺乏对于代码架构的大局观，尤其是在第四单元，甚至一个类超出了500行。但是虽然整体架构上未能完成自上而下的设计，但是能够熟练地自下而上地根据需求设计。OO的设计方法根本上来说就是everything is subject，这样的设计理念可以将每一个小的需求，都设置一个类，这样可以增强代码的可维护性和可扩展性。

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

以前理解的测试程序就是简单的进行标准输入，查看标准控制台输出。但随着互测趣味的增加，有着测试大量代码的需求，所以就自己尝试着自己去写脚本测试数据，尤其是在表达式求导单元，还接住了别的工具对表达式进行化简最后比对表达式是否相等。自己写过数据生成器，但是感觉自己的数据生成器可能有些简单，还是会出现代码的bug测不出来的现象。但是电梯单元是没有很好的学习如何自动检测数据的正确性，所以可能那单元强测出现了比较大的问题。总之数据是在随着需求变化的，测试也应该跟随数据不同而采取不同的测试方法，这样才能不断进步。

四、课程收获

本课程可以说是给了我很多的思维设计，不单单是学会使用java，类似于递归下降、分治策略、添加缓冲层等等这样的设计理念在任何程序语言都同样用得到。虽然代码自下而上慢慢完成需求是很自然地，但是我认为好的架构需要在写代码之前就设计好需要哪些工具，需要多少类，采取怎样的策略能够使代码的可维护性和可拓展性提高，虽然还不能很好地理解这一理念，但我认为这个课程已经给了我一个起点，我可以在已经学习了的知识的基础上进行更多的练习，代码量不够就用代码量去补足，总能达到看见需求就有自上而下架构设计的思路这样的一个境界。

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

今年是OO课程的第一次大改革，虽然我没有经历以前的OO课程，但是我认为这门课程是本学期最良心的，老师给力，助教乐意解答问题，这是一个很大地“用户体验”的提升。面向对象的设计思想应该说我们只是入了个门，如果想熟练运用这一实用的工程思想，也许还需要多多进行代码设计。给课程组的建议如下：

1、重新权衡中测数据的强度

虽然考虑到中测是需要考虑全体同学平均水平的，仅仅为了检测是否完成本次作业的基本需求。但是往往会因为代码很小的疏忽，因为自己手头数据不足，或者未能够考虑到课程组对于数据的设计意图，强测成绩不堪入目。虽然直接完成一份完善的代码是一种能力的体现，但是毕竟写代码不像高考，即便输入再多的心血设计自己的架构，但是只要有疏忽往往容易造成满盘皆输的局面，但提高中测数据的强度可以很好的改善这一局面。希望以后课程组可以重新权衡一下中测数据的强度。

2、理论课增加对于代码的介绍

理论课虽然是介绍理论知识，但是还是希望能够有一些对于某些功能的示范性代码，这样不仅可以提高课堂的趣味性（因为我认为读代码猜设计意图本身还是很有趣的），还可以将实践和理论联系起来，也许效果会更好一点。

3、重新设计实验课的内容

实验课很多时候是不知所云，上午刚学的知识下午就要实现，这中间有点赶，缺乏一个消化知识的过程。或许可以考虑延长实验课的持续时间，也可以达到对于知识检测的目的，不一定就要按照规定时间完成需求。