OO第四单元总结

OO第四单元总结

1、第四单元做业总结

本单元主要有两个任务：

1. 对UML类图进行解析。

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

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

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

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

类图以下：

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

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

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

类图以下：

3.第四单元教训总结

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

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

一、第一单元架构设计

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

二、第二单元架构设计

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

三、第三单元架构设计

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

四、第四单元架构设计

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

五、OO方法理解

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

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

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

4、课程收获

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

5、立足于本身的体会给课程提三个具体改进建议

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

一、从新权衡中测数据的强度

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

二、理论课增长对于代码的介绍

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

三、从新设计实验课的内容

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