OO第四单元总结

一，第四单元作业分析###

第一次作业####

这次作业的内容是完成对UML类图的解析，要求从输入中提取并存储有关信息以支持特定的查询指令，包括类，属性，操作，关联等。与前几单元作业相比此次作业的算法难度偏低，了解UML类图的元素结构是处理好本次作业的关键。

建图时，因为元素之间存在依赖关系，所以可以对它们进行分类，最后总共需要三次循环即可存储所有元素信息。对于每一个类图元素，均为其建立一个类，其余的类存储在两个主要的类（类和接口）的hashmap中，使存储架构符合UML的类图逻辑。在实际编写中我感觉比较麻烦的是关联的处理，它既可以是接口也可以是类，起初没有考虑到这个问题我出现了nullpointer的问题，后来用了4个if才加以解决，对于其他元素，查询时可直接到相应位置寻找，总体而言感觉逻辑结构较为清晰，而且鲁棒性较高，不容易翻车。但这样未免有些繁琐，而且在实际编写中会发现很多存储的信息是查询指令中所不需要的，如果单纯为了完成指导书需求的话可以对其进行简化。
为了控制cpu时间，还加入了缓存机制，将查询某一信息时已取得的信息存储起来。以查询类实现的接口为例，先计算每一个类自身实现的接口，再对其父类向上递归，实际算出了其上所有类实现的接口，采用全局hashmap将结果存储，以便于下次可以直接使用。
相关代码如下：

 HashMap s = new HashMap<>();
        if (a.getGen().size() == 0)
        {
            s.putAll(diguijiekou(a.getInter()));
            iminter.put(a.getid(), s);
            return s;
        }
        s.putAll(diguijiekou(a.getInter()));
        s.putAll(iminter(idclass.get(a.getGen().get(0))));
        iminter.put(a.getid(), s);
        return s;

第二次作业####

相较于第一次作业加了顺序图状态图的分析，以及三条基本规则的检查，我沿用了我第一次作业的架构，新加入了诸如mystate, mylifeline等子类以适应此次作业的需求。
因为需求的简化，顺序图和状态图的处理都并不复杂，真正让我感到棘手的是关于基本规则的处理。首先对于R001，因为关联端的名字可以为空，所以如果不先做判断就会出现nullpointer的情况，且名字为空与名字为null完全是两个不同的概念，测试数据在这里设置陷阱也是在警示我们思考问题的细致程度。关于R002其实就是图中的环路问题，从一个类开始找它的父类，逐层往上，如果找到了它自己就说明此数据不符合R002规则，对于接口也是一样，通过对其继承的类或接口进行递归可以解决。对于R003的多重继承，起初我考虑只有接口才有多重继承，所以可以求出所有有多重继承的接口，然后类不可能有多继承，所以类的多重继承来自于其实现了有多重继承的接口，但我忽略了类对接口的可多重继承性导致了bug，最后我使用了最暴力的遍历方法，找出一个类实现的所有接口，如果有重复的则要抛出异常，毫无疑问这个效率是很低的，还可以再次改进。

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

第一单元
刚刚接触面向对象思维的我尚不能理解架构设计的好处，对类的使用也仅仅是为了用而用，直到第三次作业工作量明显增大时，我才感受到分类的必要性，通过建立幂函数因子，三角函数因子，表达式因子，常数因子，嵌套因子等不同的类，不仅使自己编写程序时代码逻辑更加清晰，对于debug的好处也是显而易见的。这一单元我主要学习了java的语法以及面对复杂问题的分析处理能力，对于面向对象的理解也仅仅停留在了解会使用的层面，主要还是面向过程的思维占了主导，可以说是刚刚入门了OO。
第二单元
引入了多线程电梯，是生产者消费者模式的升级版，此单元是我认为最具有面向对象特点的单元。主要有三个线程，输入，调度器，以及电梯，输入线程就是生产者，电梯就是消费者，中间由调度器来负责连接交互，相当于托盘。此单元有一个很重要的问题就是共享资源的保护以及死锁的预防，对于synchronized的使用让我理解多线程运行的安全问题。此外还介绍了单例设计模式用于共享对象的保护，在多线程中面向对象思想得以充分体现，虽然此单元程序比较复杂但我也感受到了OO的奇妙之处。
第三单元
这是关于JML的单元，使用到了很多数据结构的知识。从最初的路径演变成图，再演变为地铁系统，逐层递进。对于第三次作业，我引入了一种新的图，此图中所有在一条路径上的点之间都有一条边，最少换乘次数在这个图中就转换为两节点之间的最短路径减1，用类似的思想也可以解决最低票价与最低不满意度的问题，唯一不同的是邻接矩阵中存储的权值不同，为了限制cpu时间，每次修改图时就使用floyd算法求出所有结果，使查询复杂度为O(1)。此单元多使用继承接口可以简化代码的编写，加深了我对继承以及接口的使用意识。
第四单元
此单元主要掌握UML图的结构即可，对于图内的每一种元素可以分别定义一个类来表示，根据元素之间的依赖关系进行归类存储，理清层次，就能得到逻辑清晰的架构，debug时也能快速定位问题所在，从这一单元我认识到对结构进行合理的划分归类可以大大提高代码的可读性以及鲁棒性。

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

第一单元
这一单元的测试几乎全靠人为构造测试数据，尤其是边界数据以及WRONG FORMAT数据，此时对测试的理解并不深刻，测试效率较低。在互测时也仅仅是非常佛系的用自己构造的一些边缘数据去测别人。
第二单元
引入了多线程，测试数据针对可能造成死锁，程序crash而设计，也使用一些随机数据与其他同学程序输出结果进行对比。但由于测试的不充分强测依然出现bug，血的教训让我意识到充分测试的必要性。
第三单元
主要学会使用Junit进行单元测试，但是比较繁琐费时，而此单元的输出都是确定的，显然对拍效率更高。此单元除了正确性还有一个问题就是cpu时间，我认为时间效率问题和正确性同等重要，除了写出程序，还要尽可能的优化算法，使用一些小技巧（如缓存）来提高效率。
第四单元
使用starUML画较为复杂的类图（继承，多接口），不仅可以帮助我们理解UML，还可以构造出测试数据，此单元由于处在考期没有进行更多的测试。

四，课程收获###

一门全新的编程语言java，以及良好的代码风格
面向对象的编程思想以及使用技巧
理解设计架构的重要性，学习扩展性强规范化层次化的结构设计
多线程编程设计以及一些常用的设计模式
多线程中处理共享资源以及预防死锁的设计训练
学习JML规格设计思想，以及UML的分析使用
理解了测试的必要性，学习对程序进行全面测试压力测试
学习了常用的优化效率技巧以减少cpu时间提高程序效率

五，课程建议###

个人认为第二单元的多线程是很体现面向对象编程思维的，然而自从电梯之后我就再也没有在作业中使用过多线程，也许以后可以再增加一些多线程的相关内容
大部分情况下互测很难有时间去看那么多人的代码，是否有违互测机制的本意？也许可以加以改进
OO的实验课给人感觉很迷，不算硬性的考试，只是为了让我们熟悉最近理论课学习的相关知识，但是没有进一步讲解做完之后就不了了之感觉有些不妥