对于下文类图中，空心菱形箭头表示被调用，空心三角箭头表示继承，虚线三角箭头表示调用接口。
第一次作业
第一次作业使用了2个类。
main类只有1个属性，没有方法，类共11行代码。
process类用来处理计算过程，只有7个属性，7个方法，分别有4,3,15,43,12,24行代码，其中match方法有1个控制分支，getint方法有4个控制分支，calculate方法有1个控制分支，print方法有4个控制分支，类共115行代码。
这次虽然有7个方法处理整个过程，但仍存在主要方法过长，次要方法过短的问题，即面向过程的思想尚未转化为面向对象的思想。
这次发现了1个bug，是在使用正则表达式的时候没有考虑-000这种情况的发生。这个bug是process类match方法里正则表达式没写对，也是在思考问题的时候没有考虑全面。
在找别人bug的时候，我是按照分支树严格设计的测试用例，不过并没有找到bug。
第一次作业给我的感觉仍像是面向过程，从代码的长度也可以看出这一点。现在回想起来，起名为process类本身就是面向过程的一种潜意识的体现。
这次作业也让我认识到了Java的强大，正则表达式解决了格式的问题，类型装换方法直接将字符串转化为数，这相对于C语言大大的简化的编程的难度与工作量。
第二次作业
第一次作业使用了6个类。
main类只有1个属性，没有方法，类共8行代码。
Dispatcher类仍是表层，有3个属性，3个方法，分别有18,3,3行代码，并分别有1,0,0个控制分支，类共31行代码。
RequestList类用以存储请求队列以及运行的主体，有5个属性，4个方法，分别有6,72,5,3行代码，并分别有0,4,0,0个控制分支，类共93行代码。
Request类用以处理请求，有4个属性，12个方法，分别有6,6,6,6,6,6,3,3,3,3,3,3行代码，均没有控制分支，类共60行代码。
Elevator类用以电梯运行，有12个属性，2个方法，分别有6,50行代码，分别有0,3个控制分支，类共69行代码。
Floor类处理楼层相关事件，有4个属性，3个方法，分别有6,13,13行代码，分别有0,1,1行控制分支，类共38行代码。
这次虽然建了6个类，但实际上Dispatcher类起到的用处十分有限：我将调度的主体部分放在了RequestList类中。而且Floor类严格来讲并没有起到用处。
从下图可以看出，Elevator.run和RequestList.setRL占了主要部分，远远超过其他程序，使得程序不平衡。
这次不管是自己还是别人都没有发现bug。我认为原因有：经过了第一次作业，大家都熟悉了正则表达式与Java的一些方法，再加上这次作业的逻辑不比上次作业复杂多少，所以大家的表现普遍比较好。不过有一点需要注意，那就是Java在输出的时候会将过大过长的数自动转换为科学表达式，会不符合格式。
这次作业我开始尝试向面向对象靠拢。成果不算明显，不过自我感觉比第一次有进步，至少对象的一些操作不是在使用的时候写，而是在定义的时候写进方法里了。尽管如此，仍避免不了主要方法代码量相较于其他方法过长的问题。
而这次是尝到了甜头。在Debug的时候明显更省事了，因为方法之间的引用，使得每个方法的长度大幅减小，代码更加清晰，而且出问题的代码的定位也更加精确。
第三次作业
第一次作业使用了7个类，1个接口。
main类只有1个属性，没有方法，类共7行代码。
Dispatcher类与第二次作业一样，并没有改动。
Scheduler继承Dispatcher类，并在此基础上增加了18个属性，重写了其中2个方法，并增加了1个新的方法。三个方法分别有32,364,76行，分别有3,30,10个控制分支，类共503行代码。
RequestList类删掉了一个方法，增加了1个属性，2个方法，均为3行代码，没有控制分支，类共93行代码。
Request类增加了2个方法，其中一个重写了toString方法，分别有3,23行代码，重写的toString有1个控制分支，类共87行代码。
Elevator类变为了处理电梯运行，删去了9个属性和除构造函数之外的另一个方法，调用了Elevator_interface接口，增加了4个方法，均为3行代码，没有控制分支，类共21行代码。
Floor类也没有改动。
这次的类除了Scheduler类外其他的从结构上来说还是比较合理的。但是从下图也可以看出，Scheduler类完全就是将全部代码揉在一起了（Scheduler.run）。所以才有了夸张的364行代码。
结构上仍是一脉相承之前的结构，将Scheduler类作为最表层，main只依赖Scheduler类，显得这两个类有一个多余。将Elevator中负责运行的部分搬到了Scheduler中，让结构更清晰了一点。
这次测试仍严格按照分支树设计用例，但没有找到别人的bug，而我自己的bug却不少，主要是因为没有仔细阅读指导书，将捎带请求的判断条件弄串了，导致指令捎带的判断出现了问题。
也正因为这次我个人开始的时候没想清楚，在写代码之后才发现思路的重大问题，中途更换的算法，导致时间紧迫，从而使得代码全部扔到了Scheduler.run()里，不仅代码过长看着费劲，而且在Debug的时候也十分费时费力。
这次我感觉应该讲同质与捎带的判定独立出来，因为使用的次数并不在少，所以这样应该能让代码看着更加简洁易懂。
心得
经过之前的学习和这三次作业，我感觉C语言编程，或者说面向过程编程，就像是搭积木，或者拼拼图，将一个个零件拼到一起，得到一个完整的程序；而Java编程，或者称为面向对象编程，就好像是搭电路，将一个个的不同功能的集成电路接到一起，通过不同的接口实现不同的功能，从而得到一块能实现目标的电路板（程序）。每一个类就好像是一个黑盒子，只能看到输入输出，而不知道中间的过程。就我个人而言，我认为面向对象的逻辑更加清晰，层次感更强。
而且，经过第三次作业，我真切地意识到设计对于整个程序的重要性。好的设计可以节约编程的时间，也可以减少bug的发生。