无需debug，通过抽象模型快速梳理代码核心流程

admin

本节主要内容：

如何通过抽象模型来梳理核心流程

从类名和注释了解类的作用
上一篇的最后，我们得到了下面的抽象模型。

可以看到，最下面的三个类RunnerScheduler、RunnerBuilder和Statement，和其它的类没什么关系，我们可以暂时忽略它们。
从上面的调用关系和依赖关系，我们可以知道：

FrameworkMember是个抽象类

其有两个子类FrameworkField和FrameworkMethod

FrameworkMember和TestClass都实现了Annotatable接口

TestClass调用了FrameworkField、FrameworkMethod两个类和MemberValueConsumer接口

线条说明：
白色虚线箭头：关联关系，表现为箭头头部的类作为箭头尾部类的方法参数
白色实线箭头：组合关系，表现为箭头头部的类作为箭头尾部类的字段
蓝色实线箭头：继承关系，表现为箭头尾部的类继承了箭头头部的类
绿色虚线箭头：实现关系，表现为箭头尾部的类实现了箭头头部的接口
前面的文章中还有两种箭头
黄色虚线：注解依赖，即一个类使用了某个注解
红色实现：内部类，即一个类是另一个类的内部类

我们分别打开这几个类的源码（选中对应的类，按下F4）来阅读类上的注释，通过类名和类上的注释，我们可以了解到：

TestClass是「测试Class」的抽象。例如前面的PersonTest，它是PersonTest.class的抽象。

FrameworkField是测试类中的属性或影子属性(包装属性)

FrameworkMethod是测试类中的方法或影子方法(包装方法)

Annotatable只是统一了获取注解的接口

MemberValueConsumer用于收集对应的FrameworkMember的值

影子属性和影子方法是JUnit注释里的说法，我们暂时先这么称呼。结合前面的概念模型，猜测和Rule有关系。

构建初步流程
从类的功能，我们可以梳理出一个大概的流程：

TestClass对「测试Class」进行抽象

将「测试Class」中的字段封装为FrameworkField

将「测试Class」中的方法封装为FrameworMethod

将field和method执行的结果存到MemberValueConsumer中

找出关键方法
从上面的流程，我们可以梳理出一些关键方法：

TestClass应该会接收一个Class类型的参数来构建实例。

同时TestClass应该有方法来解析Class里的field和method，并分别构建为FrameworkField和FrameworkMethod

TestClass中应该有方法来将field和method的值设置到MemberValueConsumer中

FrameworkField应该有方法来获取自身的值

FrameworMethod也应该有方法来获取自身的值

通过IDEA的Structure视图，我们可以很快的定位到对应的方法：

TestClass中有一个有参的构造方法，接收Class类型的参数

通过scanAnnotatedMembers方法扫描方法和属性，来构建FrameworkField和FrameworkMethod

注意最后两行，makeDeeplyUnmodifiable方法是干嘛用的呢？看名字是将对象转换为不可变的，为什么要转换成不可变对象呢？

转换为不可变对象无非两种情况：

不希望对象被修改，特别是多线程情况下，可能会有不可预期的修改

没有修改，也就可以安心的使用多线程，不用考虑锁的问题。

不过由于此方法非核心方法，我们就暂时不管了。并不影响流程梳理。此问题可以留到后面再来思考答案。
我们继续看scanAnnotatedMembers方法：

分别遍历方法和属性，将其加入到对应的Map中

注意这里的MethodSorter，它对方法进行了排序

另外可以发现TestClass中有两个方法collectAnnotatedFieldValues和collectAnnotatedMethodValues，从名字就可以了解到，这两个方法是用于获取字段和方法的值，并设置到了MemberValueConsumer中。


至此，我们也就梳理出了核心流程，虽然还有几个疑问，但是没关系，我们后面慢慢来解答。

总结
本文阐述了基于抽象模型来梳理核心流程的方法，并通过JUnit来演示具体的梳理核心流程的方法。
下文将对核心流程绘制流程图图，同时将核心流程图和我们的概念模型及抽象模型进行整合，绘制出一个更完整的执行流程图。