OO大总结
UML & OO学期总结
第四单元总结
架构设计
UML是一棵树
于是最开始的思路就是按照树的层次来组织的架构。这里吃了不懂uml的亏……没有想到实际上的uml结构是一张图。
由于uml模型树的层次是有限的，我用了一个嵌套HashMap来实现uml树的管理和查找等功能。其中，由于name的可重复性，Map的key使用独一性的id。为了快速查找，再单独建立name和id的映射。
一个类500行实在写不下 为了更好的可读性和架构，将几种图分别建立类。
/*类图的管理*/
// 以class或interface为顶层的树
private HashMap<String/*classOrInterfaceId*/,HashMap<ElementType, HashMap<String/*id*/,String/*name*/>>> generalClass;
// name到id的映射
private HashMap<String/*name*/,HashMap<String/*id*/,ElementType>> nameToId;
/*顺序图的管理*/
private HashMap<String/*id*/,HashMap<ElementType,HashMap<String/*id*/,
String/*name*/>>> general;
/*状态图的管理*/
private HashMap<String/*region*/,HashMap<ElementType,HashMap<
String/*id*/,String/*name*/>>> general;
//状态图的查找按理来说需要一个封装好的图类...
private HashMap<String,HashMap<String,ArrayList<String>>> stateGraph;
/*有效性检查用类图的模型*/
第二次的类图如下：
易发bug
name为null导致的NullPointerException- 有的
UmlElement没有parent，查找的时候导致NullPointerException
学期总结
架构设计及OO方法理解的演进
-
第一单元-多项式求导
刚开始写第一单元作业的时候，对面向对象几乎没有概念。最主要的是，没有封装和代码可读性的意识。所理解的“架构”也只包括具体的数据结构。
体验着重构一时爽一直重构一直爽的第一单元作业。 第一次作业惨绝人寰地只用了两个类面向过程，并且看着求导简单就直接用了公式。第二次简单封装了几个类，但在整体架构上不知悔改，仍然用了复杂一点的公式。第三次才痛改前非使用树形结构求导。这是我第一次明白可扩展性的重要性。
- 第一次作业类图（不忍卒读）
- 第二次作业类图
- 第三次作业类图
-
第二单元-多线程电梯
初次接触多线程。这一单元由于第一次就考虑了后续电梯的扩展性，完成得十分轻松愉悦。从第一次开始就模拟了真实电梯的运行情况和调度算法，将算法、调度、运载人等分别封装，后面的两次作业就是一路复用了，感受到了面向对象扩展性的好处。
第二次作业的顺畅很大程度上归功于真实世界中存在的参照物。仿照现有电梯的运行让架构变得容易了许多。然而以后要面对的可能还有很多缺乏参照物的对象，因此在编码之前的构思就显得尤为重要。
- 第五次作业类图
-
第六次作业类图
同上
-
第七次作业类图
第七次代码非常不美观的一点是，没有把不同功能的电梯抽象出一个父类。（主要的问题是对单例模式的不熟悉。
-
第三单元-路径管理
第三单元有个特点是有官方包，只需要自己实现接口。我认为第三单元的在架构方面的侧重点在于对数据结构和算法在面向对象设计中的理解。例如，本次作业有很多图的相关操作和算法，应该与容器分离开来。（这一点上自己做得很不好，甚至还由于算法的不熟悉险些出bug。）
- 第九次作业类图
- 第十次作业类图
- 第十一次作业类图
-
第四单元-uml
面向对象总结性的一个单元。具体前文已经写了，这里不再赘述。
测试理解与实践的演进
-
第一单元
第
WRONG一FORMAT单元的测试要点不在于程序主体的正确性而反而在于格式检查，感觉算是加强我们的代码鲁棒性意识。不仅是正确性，还需要考虑正则爆栈等性能问题。测试在于各种字符串格式的全面性，需要尤其注意边界数据的构造。 -
第二单元
第二次的重点主要在于多线程的安全性测试，通过逻辑来检查是否有死锁等情况出现。
-
第三单元
第三单元开始使用JML来验证程序正确性，并且使用Junit来进行单元测试，使测试的全面性和精准性提高了不少。由于第三单元比较依赖算法，使用Junit可以快速定位程序中的bug。
-
第四单元
和第三单元的测试类似。
课程收获
-
面向对象的思想与架构的设计
-
Java语言的接触（事实上只是初步接触，还有很多高级特性尚需学习）
-
代码能力的提高。代码行数统计如下：
单元 第一次 第二次 第三次 一 418 976 1504 二 424 436 1079 三 242 366 705 四 481 1284 -- 除可见的代码行数外，debug的过程也很锻炼能力（雾。
-
各种工具的使用。例如jml、junit、uml等
-
熬夜能力（ddl前肝代码）、对需求更改的忍耐能力（指导书难免有疏漏之处）、友善度（互测不刀人）、反思自觉性（我又哪里做错了？）、泰山崩于前而色不变的气度（卡线提交）总而言之，对生活的热爱🙂
改进建议
- 提高准时度。作业临时延期等确实很扰乱个人计划以及……心情。建议提前考虑好安排。
- 指导书的细节尽量完善。否则不常关注讨论区或者网站通知的同学会很吃亏。
- 提高中测的难度，但降低有效作业的门槛。目前中测存在的问题在于：
- 数据过弱导致不能很好地帮助同学们检测代码正确性（当然也一定程度上锻炼了我们自己的测试能力）
- 有隐藏点，可能有些同学因为微小、不在主要测试目标内的bug导致了无效作业（而强测分不一定低）
- 实验课的课程安排。上午上课下午实验，感觉不太有时间消化课堂内容。
- 第四单元作业改进。没有感觉出来第二次与第一次的差别在何处。
虽然没有要求但还是要加上的夸夸环节
-
预热阶段的良心教程。让同学们的OO之旅开始得十分顺畅。（虽然，于我个人而言，仍然是开学之后写的暑期作业）
-
互测屋机制。多人互测降低了得分的随机性。后来的匿名、隐藏hack数等操作也将同学们的重心更加放在了“测试”上，对单纯的得分的关心少了很多。
-
官方包。官方包的工程量很大，赞点在于助教们及时相应同学们的需求，增加接口等方面。
-
作业设计。每单元的设计都是环环相扣，
反思重构体验++。
总之，OO课程体验十分良好，能感受到老师和助教们的辛苦。希望OO课程能够越来越好。
