OO第四单元总结——查询UML类图暨 OO课程总结

一、本单元两次作业的架构设计总结

作业一、UML类图查询

1. 统计信息图

2. 复杂度分析

基本复杂度（Essential Complexity (ev(G))、模块设计复杂度（Module Design Complexity (iv(G))）、Cyclomatic Complexity (v(G))圈复杂度

OCavg为平均循环复杂度;WMC为总循环复杂度

3. 结构信息图

4. 分析架构设计

本次没有架构设计,本次只用了两个类，一个main类，用于启动，一个MyUmlInteraction类，实现了UmlInteraction接口，在MyUmlInteraction类的内部实现所有的方法。这种架构设计的实现很简单，但是会使整个类的复杂度升高，不易于debug和扩展（比如写完成品后我类的长度达到了480+行，十分接近500行的上限了）。

作业二、UML类图、状态图、顺序图查询

1. 统计信息图

2. 复杂度分析

基本复杂度（Essential Complexity (ev(G))、模块设计复杂度（Module Design Complexity (iv(G))）、Cyclomatic Complexity (v(G))圈复杂度

OCavg为平均循环复杂度;WMC为总循环复杂度

3. 结构信息图

4. 分析架构设计

本次作业使用了6个类，一个main类，用于启动，一个MyUmlGeneraIInteraction类，实现了UmlGeneraIInteraction接口。MyUmlGeneraIInteraction类内含有四个类，MyStateChart类（实现状态图的查询指令），MyStandardPreCheck类（实现后两个检查指令），MyCollaboration类（实现顺序图的查询指令），MyClassModel类（实现类图的查询指令，以及第一个检查指令）。

四个类其实分别对应UmlGeneraIInteraction接口实现的四个接口，分别实现对应接口内的方法，进行架构的简单解耦。解耦的效果不错，debug和扩充的体验都不错。

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

1.第一单元——面向过程

第一单元的架构设计还没有摆脱面向过程的思想，次次作业重构程序，之前的程序能用到的只有部分思路以及极小部分代码。可扩充性差，维护性差。

不过在这个过程中，逐渐了解了什么是面向对象，什么是继承，什么是接口，什么是抽象类，什么是包等等一系列将要用到的东西。

在第三次作业（上图）中，建立了一个自我感觉良好的架构，将因子和嵌套方式单独建包以及抽象类，一切看起来井井有条。但实际上面向对象只是形象工程，骨子里还是面向过程，请看以下代码：

 1             if (matcherNum.matches()) {
 2                 stringBuilder.append("0");
 3             } else if (matcherPowerFunc.matches()) {
 4                 FactorX factorX = new FactorX(addList.get(i));
 5                 stringBuilder.append(factorX.derivation());
 6             } else if (matcherTriFunc.matches()) {
 7                 FactorTri factorTri = new FactorTri(addList.get(i));
 8                 stringBuilder.append(factorTri.derivation());
 9             } else {
10                 ItemMultiIply itemMultiIply =
11                         new ItemMultiIply(addList.get(i), depth + 1);
12                 stringBuilder.append(itemMultiIply.derivation());
13             }

我建立了Factor抽象类，但是重来没有使用过抽象类的真正功能，调用时还是if ...(FactorX) else ....(FactorTri)，没有领会到面向对象的精髓——多态是如何使用的。

2.第二单元——多线程与SOLID分析

在第二单元里，我知道了多线程程序的实现方法。并且在第一次作业时，将解耦进行到底，Elevator类中的方法极力拆分，使模块化方法与功能一一对应，为第二次作业打下了良好的基础。

下面左图是第一次作业的架构信息图，右图是第二次作业的架构信息图。不难发现，两者之间的区别只有Elevator类中多了一个方法，Scheduler类中多了两个方法。扩充性很好，第二次作业写的非常舒服。

但问题出在了第二次作业，没有考虑到多电梯实现时的调度问题，将一部分Schedule类的工作放在了Elevator类中（sort方法），导致第三次作业解耦困难，并且还出现了不少bug。

下图是第三次作业中最不应该出现的程序代码，这个非常复杂且诡异的代码（另外加上两个类的多个方法），只是为了解决什么时候停止运行这个比较简单的问题，然而最后恰恰出错在了此处。我觉得跟该处代码的复杂度高，逻辑混乱有很大的关系。

 1                 if (order.get(0).get(1) == 0) {
 2                     if (order.size() == 1) {
 3                         order.remove(0);
 4                         boolean end = false;
 5                         empty.setEmpty(name);
 6                         while (true) {
 7                             if (empty.isEmpty() & (elevScheduler.Num() == 0)) {
 8                                 if (!closeDoor) {
 9                                     close();
10                                 }
11                                 end = true;
12                                 break;
13                             }
14                             if (elevScheduler.Num() != 0) {
15                                 ArrayList<ArrayList<Integer>> integer
16                                         = elevScheduler.pop();
17                                 if (integer.get(0).get(1) == 0) {
18                                     sleep(100);
19                                     continue;
20                                 }
21                                 order.addAll(integer);
22                                 empty.setFull(name);
23                                 break;
24                             }
25                             sleep(100);
26                         }
27                         if (end) {
28                             break;
29                         }
30                     }

3.第三单元——继承与接口

这一单元里我使用了不少继承和接口实现，优点在于学会了分离一部分有联系的核心代码到单独的类里（比如都是与图相关算法的代码），并支持传入数据的类型多样（实现了多态），即同一个图的方法可以对不同储存结构的图使用。

 1 void floyd(HashMap<Integer, HashMap<Integer, Integer>> dist) {
 2         for (Integer integerA : dist.keySet()) {
 3             for (Integer integerB : dist.keySet()) {
 4                 if (!dist.get(integerA).containsKey(integerB)) {
 5                     continue;
 6                 }
 7                 for (Integer integerC : dist.keySet()) {
 8                     if (dist.get(integerA).containsKey(integerC)) {
 9                         Integer tmp = dist.get(integerA).get(integerC) +
10                                 dist.get(integerA).get(integerB);
11                         if (!dist.get(integerC).containsKey(integerB) ||
12                                 tmp < dist.get(integerC).get(integerB)) {
13                             HashMap<Integer, Integer> has1 = dist.get(integerC);
14                             has1.put(integerB, tmp);
15                             dist.put(integerC, has1);
16                             HashMap<Integer, Integer> has2 = dist.get(integerB);
17                             has2.put(integerC, tmp);
18                             dist.put(integerB, has2);
19                         }
20                     }
21                 }
22             }
23         }
24     }

 1      void addEdge(Integer nodeA, Integer nodeB, int weight,
 2                  HashMap<Integer, HashMap<Integer, Integer>> init) {
 3         HashMap<Integer, Integer> tmpA = new HashMap<>();
 4         HashMap<Integer, Integer> tmpB = new HashMap<>();
 5         if (init.containsKey(nodeA)) {
 6             tmpA = init.get(nodeA);
 7         }
 8         if (init.containsKey(nodeB)) {
 9             tmpB = init.get(nodeB);
10         }
11         if (nodeA.equals(nodeB)) {
12             tmpA.put(nodeB, 0);
13         } else {
14             tmpA.put(nodeB, weight);
15             tmpB.put(nodeA, weight);
16         }
17         init.put(nodeB, tmpB);
18         init.put(nodeA, tmpA);
19     }

缺点在于，没有用继承的方式将三次作业的内容结合起来，而是采用最简单的复制粘贴的方法。实在是太懒了。

4.第四单元——伪面向对象

第四单元，也是OO课的收官单元，虽然难度不大，但是具有很多面向对象的特征。因为是实现一个接口，所以这使得我在完成作业的时候，也采用面向对象的思维思考程序的架构设计，对于类似的查询指令，建立统一模型，采用一样的思路执行。不过遗憾的是，程序完成过程中，出于懒的想法，还是以代码复制的形式实现了统一建模，没有使用统一方法。

 1     private void updateAttriResult(String classId) {
 2         if (generMap.containsKey(classId) && !attriResult.containsKey(
 3                 generMap.get(classId).get(0).getTarget())) {
 4             updateAttriResult(generMap.get(classId).get(0).getTarget());
 5         }
 6         if (!attriMap.containsKey(classId)) {
 7             attriMap.put(classId, new HashMap<>());
 8         }
 9         if (!generMap.containsKey(classId)) {
10             attriResult.put(classId, attriMap.get(classId).size());
11         } else {
12             attriResult.put(classId, attriMap.get(classId).size() +
13                     attriResult.get(generMap.get(classId).get(0).getTarget()));
14         }
15     }

 1     private void updateAssocResult(String classId) {
 2         if (generMap.containsKey(classId) && !assocResult.containsKey(
 3                 generMap.get(classId).get(0).getTarget())) {
 4             updateAssocResult(generMap.get(classId).get(0).getTarget());
 5         }
 6         if (!asEndMap.containsKey(classId)) {
 7             asEndMap.put(classId, new HashMap<>());
 8         }
 9         if (!generMap.containsKey(classId)) {
10             assocResult.put(classId, asEndMap.get(classId).size());
11         } else {
12             assocResult.put(classId, asEndMap.get(classId).size() +
13                     assocResult.get(generMap.get(classId).get(0).getTarget()));
14         }
15     }

在第二次作业里，我采用建立四个类，分别对应UmlGeneraIInteraction接口实现的四个接口，分别实现对应接口内的方法，进行架构的简单解耦，收效不错。

5. 总结

其实总的来看四个单元，面向对象的思维不一定是一直增加的，应该是螺旋式上升的，中间也会遇到误区，重新回到老路子上。不过整体来讲，现在对面向对象的思维和架构设计理念有了一定的了解，同时体会到了面向对象思维的优势强大。

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

1.第一单元——刀耕火种

一开始接触到OO，是一脸懵B的，咱什么都不知道，也不敢问

回顾一下我在第一单元总结时写的测试分析，当时是多么渴望一个评测机啊~

初期的评测全程手动，一行行阅读别人的代码，仔细思考逻辑关系，试图发现漏洞，当时简陋的条件下，硬是靠着眼力，看出了不少bug，虽然方法粗糙，但是这种方法是白盒测试，我清楚的知道他为什么出错，甚至知道怎么改正这个错误，对bug出现的方式以及易错点有了更多的了解。（后期测评机上线后就是“床上一躺，电脑一响”）

2.第二单元——初识评测机

回顾一下我在第二单元总结时写的测试分析，明显看出评测机的效率惊人，虽然没能测出自己的bug（因为生成数据不够全面），但对于互测来讲，简直是天降神兵。

错误原因我是单独看错误输出和大致的程序思路，总结出来的。（也算是没有完全的黑盒测试）

3.第三单元——加强评测机

在经历了第二单元的测评机数据生成不够强的问题后，我们每次同时有多个同学并行写数据生成的程序，扩大覆盖面。并且从网上找了一个评测结果的现实页面（网页），还是很实用的，如下图（标黄的为不同处）：

并且，我开始重视每一个bug，更重要的是每一个bug的产生原因，防范于未然。从我第三单元总结的测试分析中就可见一斑:

4.第四单元——展望未来

第四单元临近烤漆，没有对评测机做大的改动，基本上沿用了上一单元的思路，只需要重写数据生成程序。

对于未来的评测机（什么时候会用到呢？），我有一些自己的构想，希望能加入错误分类机制，就像buaaoo平台一样，可以提供错误类型及错误定位信息。错误类型的实现较为容易，我们也尝试过，但因为用途不大最终没有采用。错误定位信息的生成比较困难，尤其是我们现在的评测机大部分是对拍器，不是真正意义上的评测机。

最后，想感谢助教和老师们的辛勤付出，才有了比较健全的buaaoo的judge系统，因为自己写过才知道很不容易，所以，十分感激~~

四、课程收获总结

OO课程收获还是很多的，从一个什么都不会的OO小白，到一个看起来会OOP实际OPP的伪小白。

java从入门到熟练（熟练的，不一定是代码，也可能是BUG）
从面向过程编程到面向对象编程，最起码现在写程序前，会想一下数据之间有没有什么联系，需不需要建类，需不需要继承...
搭评测机的过程中，复习了Python，认识了shell，重装java\python环境熟练。
意识到测试的重要性，随机数据和手捏数据都不能少 & 测试永远不会多，测试多一点，炸点少一点
意识到架构的重要性，一时重构一时爽，一直重构一直爽
发现了很多易错点，尤其是多线程单元的作业，希望吃一堑长一智
......

五、给课程的三个具体改进建议

1. 希望强测也引入互测中的同质bug修复机制，减少因同质bug导致的强测大面积WA

2. 希望架构方面的因素能体现在分数之中，这样同学会花更多的时间在架构设计上，而不是像我一样有时懒得管架构了（逃

3. 希望每个单元都有一定比例的性能分（具体指标没想出来），这样有利于分层

谢谢助教和老师们一个学期的辛苦付出~~

感谢拉我一把的各位大佬们orz

感谢屡败屡战苟活到现在的自己

~~OO完结撒花~~

posted @ 2019-06-22 00:00 _ETO 阅读(306) 评论(1) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

_ETO

OO第四单元总结——查询UML类图 暨 OO课程总结

一、本单元两次作业的架构设计总结

作业一、UML类图查询

1. 统计信息图

2. 复杂度分析

3. 结构信息图

4. 分析架构设计

作业二、UML类图、状态图、顺序图查询

1. 统计信息图

2. 复杂度分析

3. 结构信息图

4. 分析架构设计

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

1.第一单元——面向过程

2.第二单元——多线程与SOLID分析

3.第三单元——继承与接口

4.第四单元——伪面向对象

5. 总结

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

1.第一单元——刀耕火种

2.第二单元——初识评测机

3.第三单元——加强评测机

4.第四单元——展望未来

四、课程收获总结

五、给课程的三个具体改进建议

公告

OO第四单元总结——查询UML类图暨 OO课程总结