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.第一单元——面向过程

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

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

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

if (matcherNum.matches()) {
stringBuilder.append("0");
} else if (matcherPowerFunc.matches()) {
FactorX factorX = new FactorX(addList.get(i));
stringBuilder.append(factorX.derivation());
} else if (matcherTriFunc.matches()) {
FactorTri factorTri = new FactorTri(addList.get(i));
stringBuilder.append(factorTri.derivation());
} else {
ItemMultiIply itemMultiIply =
new ItemMultiIply(addList.get(i), depth + 1);
stringBuilder.append(itemMultiIply.derivation());
}

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

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

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

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

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

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

if (order.get(0).get(1) == 0) {
if (order.size() == 1) {
order.remove(0);
boolean end = false;
empty.setEmpty(name);
while (true) {
if (empty.isEmpty() & (elevScheduler.Num() == 0)) {
if (!closeDoor) {
close();
}
end = true;
break;
}
if (elevScheduler.Num() != 0) {
ArrayList<ArrayList<Integer>> integer
= elevScheduler.pop();
if (integer.get(0).get(1) == 0) {
sleep(100);
continue;
}
order.addAll(integer);
empty.setFull(name);
break;
}
sleep(100);
}
if (end) {
break;
}
}

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

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

void floyd(HashMap<Integer, HashMap<Integer, Integer>> dist) {
for (Integer integerA : dist.keySet()) {
for (Integer integerB : dist.keySet()) {
if (!dist.get(integerA).containsKey(integerB)) {
continue;
}
for (Integer integerC : dist.keySet()) {
if (dist.get(integerA).containsKey(integerC)) {
Integer tmp = dist.get(integerA).get(integerC) +
dist.get(integerA).get(integerB);
if (!dist.get(integerC).containsKey(integerB) ||
tmp < dist.get(integerC).get(integerB)) {
HashMap<Integer, Integer> has1 = dist.get(integerC);
has1.put(integerB, tmp);
dist.put(integerC, has1);
HashMap<Integer, Integer> has2 = dist.get(integerB);
has2.put(integerC, tmp);
dist.put(integerB, has2);
}
}
}
}
}
}

void addEdge(Integer nodeA, Integer nodeB, int weight,
HashMap<Integer, HashMap<Integer, Integer>> init) {
HashMap<Integer, Integer> tmpA = new HashMap<>();
HashMap<Integer, Integer> tmpB = new HashMap<>();
if (init.containsKey(nodeA)) {
tmpA = init.get(nodeA);
}
if (init.containsKey(nodeB)) {
tmpB = init.get(nodeB);
}
if (nodeA.equals(nodeB)) {
tmpA.put(nodeB, 0);
} else {
tmpA.put(nodeB, weight);
tmpB.put(nodeA, weight);
}
init.put(nodeB, tmpB);
init.put(nodeA, tmpA);
}

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

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

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

private void updateAttriResult(String classId) {
if (generMap.containsKey(classId) && !attriResult.containsKey(
generMap.get(classId).get(0).getTarget())) {
updateAttriResult(generMap.get(classId).get(0).getTarget());
}
if (!attriMap.containsKey(classId)) {
attriMap.put(classId, new HashMap<>());
}
if (!generMap.containsKey(classId)) {
attriResult.put(classId, attriMap.get(classId).size());
} else {
attriResult.put(classId, attriMap.get(classId).size() +
attriResult.get(generMap.get(classId).get(0).getTarget()));
}
}

private void updateAssocResult(String classId) {
if (generMap.containsKey(classId) && !assocResult.containsKey(
generMap.get(classId).get(0).getTarget())) {
updateAssocResult(generMap.get(classId).get(0).getTarget());
}
if (!asEndMap.containsKey(classId)) {
asEndMap.put(classId, new HashMap<>());
}
if (!generMap.containsKey(classId)) {
assocResult.put(classId, asEndMap.get(classId).size());
} else {
assocResult.put(classId, asEndMap.get(classId).size() +
assocResult.get(generMap.get(classId).get(0).getTarget()));
}
}

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

5. 总结

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

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

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

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

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

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