错误输出：

（无输出）

正确输出：

Failed when check R002, class/interface (W11, W112, W14) have circular inheritance.

错误分析：
  
  错误出现在第二次作业规则R002的检查。R002为不能有循环继承。错误原因是检查规则R002的函数陷入了死循环，没有跳出来。具体来说，错误代码中判断某个类C是否循环继承的算法是：采用图的广度优先搜索BFS算法，若算法成功结束，则表明以C为起点的图中没有形成以C为起点和终点的环；否则，若BFS搜索时再次搜索到类C，表明产生了循环继承。值得注意的是，BFS算法的循环跳出条件是：循环队列为空或再次搜索到起点。事实上，若按上述算法，对于该案例，算法可以发现类W11，W12，W14都有循环继承，而对于类W15，以W15为起点进行BFS搜索，W11，W12，W14这三个类会不断被加入队列，导致死循环。对于此错误的改进方法是：用一个Set记录所有进到过队列中的元素，BFS算法每次遍历到的结点需要先经过一层判断，若Set中包含该结点，则表明此结点形成了环，已经被遍历过，不能加入队列中。
  

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

3.1 第一单元架构设计

  
  第一单元为Java语言及面向对象机制入门，三次作业难度由浅入深，从类图便可看出。第一次作业简单多项式的求导，对于Java不熟练，仿照C语言的方式写一两个函数便可完成；而第三次作业暗含嵌套结构以及继承的特征，若继续用以前C语言的编码方式，代码量将成倍地上涨。只有活学活用Java的面向对象机制，掌握继承与接口封装，才能事半功倍。第三次作业使用了继承的Class定义方式，而前两次作业都未使用。例如，Const、Power、Sin、Cos、(Expr)，这几类都属于因子，因此我们可以定义一个Factor类作为父类，上述五个类作为Factor的子类拓展其属性和方法。若按此继承方法封装类，在求导、合并同类项时，Java的多态机制便可以体现得淋漓尽致，减少了编码量，同时更使得代码看起来整齐易懂。
  

3.2 第二单元架构设计

  
  第二单元引入了线程的概念，用多线程机制来模拟实际生活中的多电梯调度系统。本单元可分为三次难度不断递进的小作业：单步多线程傻瓜调度（FAFS）电梯的模拟、单步多线程可捎带调度（ALS）电梯的模拟、多部多线程智能调度（SS）电梯的模拟。
  
  第一次作业我构建了一个队列Queue用来管理请求PersonRequest，它相当于生产者消费者问题中的共享数据区。电梯线程仿佛消费者，不断从Queue里取出请求并满足该请求；任务接收器仿佛生产者，只要ElevatorInput出现了新的请求，就将其加入队列。当共享数据区为空时，需要阻塞电梯线程继续消费数据；这对应于实际生活中若没有客人请求使用电梯，电梯就应该暂停运行。而与经典生产者消费者问题不同的是，Queue没有长度限制，也就是不存在队列已满无法接收请求的状况。由于任意调度策略均视为正确，我们采用最朴素的先来先服务调度（FIFO）原则，这也与共享数据区是一个队列Queue结构相符。电梯线程每次从Queue中取出一个请求，电梯内最多只有一个乘客，待满足完该乘客的请求后，再从Queue中取下一个请求进行满足。所以电梯类需要保存的属性是共享队列Queue，和电梯当前到达的楼层floor两个属性。数据共享产生冲突，致使线程不安全。在我的设计中，电梯线程和任务接收器线程（也就是消费者线程和生产者线程）不做任何wait(), notify(), lock, syncronized的处理。只要保证共享数据区Queue的安全性，生产者和消费者线程就不会数据冲突问题。电梯线程从Queue取请求，任务接收器向Queue中加入请求。可能产生的冲突在于Queue的读写冲突和写写冲突。只要将对于Queue的读写操作用锁机制保护起来，就保证了程序线程安全。
  
  第二单元第二次作业换汤不换药，除了调度策略需要有所改动外，生产者消费者机制依然可以套用。程序依然分为三个线程：主线程、电梯线程、任务接收器。构建一个队列Queue用来管理请求PersonRequest，作为共享数据区；电梯线程作为消费者；任务接收器作为生产者。与第一次作业不同的是电梯调度策略的改进，电梯内不能仅仅是一个人，运行捎带。于是对于电梯线程，每当其停靠一个楼层时，都要判断在Queue中是否有请求可以捎带。捎带请求的条件是：该请求的初始楼层与电梯当前停靠楼层一致；且该请求要行走的方向与当前电梯运行方向一致。所以，对于电梯的属性，需要在第一次的基础上有两点改进：加入direction属性记录电梯运行方向，以便对应捎带请求的判断条件；再加入一个列表记录当前电梯内的人数和当前电梯内的乘客所对应的请求信息。线程安全问题依然出在共享资源的读写冲突和写写冲突中，与前面一次作业相同，只要用锁机制保证对于共享队列Queue的操作绝对安全即可。
  
  第二单元第三次作业采用5个线程加三个共享队列的方式实现。三个线程分别负责模拟三部电梯的运行，一个线程作为任务接收器，另一个是主线程。三个共享队列分别存储着A、B、C三部电梯需要满足的请求：队列a存储着电梯A需要满足的请求，队列b存储着电梯B需要满足的请求，队列c存储着电梯C需要满足的请求。任务接收器线程除了接收请求外，还担负着初步分配请求的任务。每当ElevatorInput读到一个请求，接收器根据其起始楼层判断该乘客需要首先乘坐哪个电梯，并生成一个“中间楼层”。若某电梯可以直达乘客的目的楼层，则中间楼层等于目的楼层；否则中间楼层与目的楼层不等，表示乘客需求无法一次性满足，该乘客需要换乘其它电梯。接收器的任务是将请求拆成起始楼层，到中间楼层，再到目的楼层。将中间楼层的数值和乘客所有信息根据乘客初始需要乘坐的电梯一并存入队列a、b或c中。同时，对于需要换乘的乘客（中间楼层与目的楼层不等），生成一个新的请求，将此请求放在“等待缓冲池”里。“等待缓冲池”的意义是，请求未被激活，当乘客从起始楼层到达中间楼层后，表示乘客可以换乘，此时，等待缓冲池中的队列才被激活，处于可执行状态。这样，我们就把第三次作业成功拆分为了三个第二次作业的组合。每个电梯线程分别有各自的请求队列，按照第二次作业中的ALS可捎带调度策略按方抓药，运行各自的线程。但值得注意的是，电梯线程仍有一点需要改变。即乘客需要离开的电梯的楼层是其中间楼层，而非目的楼层。所以，需要加入一点改进：当乘客到达中间楼层离开电梯后，判断乘客的是否已达最终目的地（中间楼层是否等于目的楼层），如已达最终目的地，则乘客请求已满足；否则，需要换乘，从等待缓冲区中找出对应该乘客从中间楼层到目的楼层的请求，激活唤醒该请求，加入对应共享队列。所以，在电梯类的属性中，还需要在第二次作业电梯类的基础上加入等待缓冲池，以便乘客到达中间楼层后访问等待缓冲池。

3.3 第三单元架构设计

  
  第三单元规格化的面向对象设计方法。第一次作业，需要完成的任务为实现两个容器类Path和PathContainer。最终实现的是一个路径管理系统。可以通过各类输入指令来进行数据的增删查改等交互。第二次作业，需要完成实现容器类Path和数据结构类Graph，最终需要实现一个无向图系统。可以像PathContainer一样，通过各类输入指令来进行基于路径的增删查改管理。还可以将内部的Path构建为无向图结构，进行基于无向图的一些查询操作。第三次作业需要完成实现容器类Path和地铁系统类RailwaySystem，最终需要实现一个简单地铁系统。可以像PathContainer一样，通过各类输入指令来进行基于路径的增删查改管理；还可以将内部的Path构建为无向图结构，进行基于无向图的一些查询操作；再可以构建一个简单的RailwaySystem地铁系统，进行一些基本的查询操作。
  
  对于第三单元第一次作业，我设计的MyPath类有两个属性：trajectory属性为一个ArrayList，即对应构造方法中传入的nodeList；set属性为一个HashSet，是轨迹中编号不同的点的集合。MyPathContainer类有如下四个属性。dataset是一系列Path对象组成的ArrayList，用来记录容器中的所有轨迹。id是一系列pathId组成的ArrayList，index为i的pathId对应dataset中index为i的path。nodeCounter属性是一个HashMap，用来记录容器中不同节点出现的个数。edgeCounter属性也是一个HashMap，用来记录容器中不同边出现的个数。nodeCounter属性和edgeCounter属性都是为了应对DISTINCET_NODE_COUNT指令所生成的私有属性。并且，nodeCounter属性和edgeCounter属性这两个属性基本建立了一张图，这对于作业二和作业三的拓展也是大有裨益的。值得注意的是，edgeCounter属性在本次作业的方法中并没有应用，只是为了可扩展性的架构添加的属性。在本文下一自然段中可以发现edgeCounter属性在后续作业中求最短路径发挥了重要作用。
  
  由于第一次作业可扩展性架构做得很好，第三单元第二次作业只加了get_shortest_distance这一个最主要函数，所以第二次作业做起来较为轻松，第一周在架构和设计上花费的时间在第二周得到了回报。MyPath类没有变化。MyGraph类在MyPathContainer类的基础上变化也不大，延用第一次作业的nodeCounter属性和edgeCounter属性这两个属性基本构建图的结构。nodeCounter属性用来记录容器中不同节点及其出现次数。edgeCounter属性用来记录容器中不同边及其出现次数。图的构建完毕。针对最短路径的计算，加入distance属性。distance属性是一个HashMap，key值是无向图中的节点编号，value值是一个从节点编号映射到最短距离的HashMap。distance记录了从节点到其可达节点的最短距离。最短距离算法：考虑到相邻节点之前的距离为1，即这是一幅权重全为1的特殊无向图。于是，BFS广度优先搜索就可以派上用场，而不必应用Dijkstra算法。从某一节点fromNode出发对图进行广度优先搜索，搜索到的节点顺序其实与Dijkstra算法搜索的节点顺序是一致的，这就保证了算法的正确性。所以以某一节点fromNode出发对图进行一次BFS搜索算法，可以得到fromNode到图中所有结点的最短距离。为了节约CPU运行时间，并不是每次addPath或removePath时都进行一遍图的广度优先搜索。每次用户进行 get_shortest_distance 查询时，先查询distance属性中是否有与fromNodeId相同的键值key，若有，则表示之前以fromNode为出发点进行过BFS搜索，则直接读取相应结果，省去了BFS搜索的时间；若没有，再进行以fromNode为起点的BFS搜索，并加搜索结果加入distance属性中。换言之，distance属性并不记录无向图中所有起点到其它所有点的最短距离，而只是记录一部分起点到其它所有点的最短距离。
  
  第三次作业在第二次作业基础上主要增加了查询最低票价、最小换乘次数、最小不满意度的计算。由于是需求是不断递进关系，每次的作业其实都可以继承上一次作业的类。例如，我在此次作业实现MyRailwaySystem类时，就继承了第二次作业的Graph类，因为除了功能在递进外，本质上地铁系统图就是一个更具体的无向图。MyPath类没有变化。而MyRailwaySystem类随继承了MyGraph类，但仍然针对最低票价、最小换乘次数、最小不满意度的查询功能增加了私有属性。nodeSet属性和edgeSet属性存储了地铁图结构，price、transfer、unpleasant三个HashMap属性原理与第二次作业中distance属性类似，分别记录了从结点到图中所有其他结点的最低票价、最小换乘和最小不满意度。与distance属性类似，为了节约CPU运行时间，price、transfer、unpleasant三个属性并不记录无向图中所有起点到其它所有点的最低票价、最小换乘和最小不满意度，而只是记录一部分起点到其它所有点的最低票价、最小换乘和最小不满意度。最低票价、最小换乘和最小不满意度算法：最低票价、最小换乘和最小不满意度算法原理完全相同，都是有向图的最短路径问题，只是各自的边权重不一样。这里以最小不满意度算法具体展开。由于边权重不再全是1，所以不能简简单单像第二次作业一样使用BFS搜索算法。我这次采用了传统的Dijkstra算法，但又与传统的Dijkstra算法稍有不同。由于引入了换乘，换乘的不满意度不为0，传统的Dijkstra算法不再具有最优子结构，我的解决方法是对地铁图做一定的改进，采用拆点的做法。具体来说：对于每个地铁站node，拆分成2+x个点，其中x为经过这个地铁站的Path数。其中，前两个点为抽象出来的起点和终点，用于解决换乘和答案统计，后面的x个点可以理解为每个Path在地铁站node的站台。之后是连边，设一条Path中相邻两个点的边权为x(双向边)，每个地铁站的终点到起点(没有写错)连边的边权为y(换乘，单向边)。x,y的值由需求决定(即四种图)。每个站台往它所在的终点连边的边权为0，每个地铁站的起点往它的每个站台连边的边权为0，图即建好。换言之，将图结构进行了改进后，图即变成了一个普通的有向图，传统的Dijkstra算法在求解最小不满意度时由于具有了最优子结构，可以发挥作用。

3.4 第四单元架构设计

  
  见本博客第一节。
  

3.5 OO方法理解的演进

  
  一个学期的面向对象课程学习下来，发现自己真的长进了不少。回首这一个学期，发现四个单元的教学设计是不断递进的，或者说是“继承”关系，或至少是强“关联”关系。
  
  本课程的4个单元模块分别是Java基础、多线程和线程安全设计、抽象与规格，测试和论证。
第一单元对象与对象化编程。主要接触了Java语言的基本语法和面向对象的设计思维，可以设计出较为简单的单线程程序，是OO课程的基础铺垫。
  
  第二单元Java运行机制及多线程。从此单元开始，难度明显上升，开始设计多线程交互系统，一方面需要实现线程间的并行，一方面需要着重注意线程安全问题。
  
  第三单元规格化的面向对象设计方法。主要进行对程序抽象与规格的设计，便于养成良好的工程化开发的习惯，同时借助对前面作业的规格设计，来进一步深入理解面向对象的编程思维。
  
  第四单元UML语言。主要则是引入了另一种语言，直接提供针对性、分离的结构与行为描述手段，而且可以在后台把描述元素整合起来。从UML类图到顺序图再到状态图，让我看到了Java程序如何与UML结合，反映自己程序的优缺点。
  
  除了四个单元之间的递进式架构外，每个单元的三次小作业也具有递进关系。从3.1 ~ 3.4小节的作业架构便可看出。比如第三单元的第一次作业中edgeCounter属性就很好地为第二次作业中最短路径的求解铺平了道路，因而我们可以认为第三单元第一次作业的架构是好的架构，是具有可扩展性的架构。
  
  除了递进式的架构外，四个单元的学习还让我学会如何工程化地开发软件。工程化开发的一般流程是需求分析—设计编码—测试验收—维护。“需求”是基本问题，既是出发点也是终结点，基于需求进行设计编码，测试验收，最终实现需求。但有时候需求也不是一成不变的，就比如我们的OO作业都有可能写着写着改指导书了，readme（对于程序员来说）是最好的解决办法，但在具体现实问题中可能事与愿违，如果前期设计包容度不够高，可能一个微小需求的变动会对整个工程开发产生很大的影响，所以，前期设计至关重要，个人认为，可能需要考虑的比需求本身更为广泛，多想一些，想长远一点。除此，一般而言，对于大型的工程项目，多是teamwork，这就需要程序员具有良好的编程习惯以及职业素养，并且在团队协作中，可能需要事先设置一些规范要求以便最终能实现高效的任务对接，但如果某个个体违背了一定的原则，且不说对整个工程开发的影响，这种行为本身就该被谴责。
  
  OO课程为我们打开了以后步入程序员岗位的一扇小窗，让我们在一轮又一轮作业中强化体会这四个环节。特别是设计和实现分离，设计好了，实现也就是解决一些小细节而已，要是没设计好就急忙动手，那必然是步步凶险且是蜗牛式前进。
  

四、四个单元的测试理解及实践演进

  
  值得说明的是，16级高工没有OO互测，没有机会去学习其他同学的代码。但发现别人程序Bug的策略和发现我自己程序Bug的策略其实是基本一致的。本博客中仅根据四个单元中在弱中强测中发现的Bug，以及自我的其它程序测试进行分析。
  
  在码好代码后，首先要根据自己的代码结构思考可能出现的问题，再加之各种覆盖性测试和鲁棒性测试。即先进行白盒测试，再进行黑盒测试。白盒测试是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。
  
  每次作业测试着重测试作业的创新点。例如第一单元的第三次作业在前两次作业的基础上又允许三角函数中嵌套因子的新规则，就着重设计对嵌套因子的求导的测试。再如第一单元第三次作业重构了代码，五种因子类都是Factor的子类，覆盖测试时就要覆盖全面，各种因子都嵌套一遍，都相加减一遍，都相乘一遍。我自己书写了两个程序：①随机生成项和因子的代码，用于生成覆盖性测试的测试集；②提取自己程序的求导结果，代入MATLAB中验证正确性的比对代码。
  
  再如第二单元的作业，我同样编写了Python程序已完成覆盖性测试。随机生成一系列的请求，PersonId依次递增，fromFloor和toFloor为在楼层范围内的随机整数（fromFloor不等于toFloor)。模型产生大量随机请求，验证程序的正确性和效率是否在datacheck给出的时间范围之内。
  
  鲁棒性测试一样重要。每次作业的需求都有不小的改变，第一单元中字符串的输入处理会千变万化，很有可能考虑不周；第二单元单次运行程序很可能不会有错，但多次运行程序可能才会发现线程安全问题；此外，没有任何请求的系统、只有单一请求的系统、只用到一部电梯的请求、错误请求、很多人同时从一层上电梯的请求......等等特殊情况都要覆盖全面。所以第二单元我着重设计了鲁棒性测试。与第一单元进行黑盒测试和白盒测试相比，第二单元更侧重线程安全的角度，所以更注重鲁棒性测试，看看程序是否会出现死锁或无限等待的情况。第三单元对于给定的规格，同样需要将规格的每个分支测试都覆盖全面。
  
  除了上述测试之外，我还学会了如何使用JUnit进行测试。通过JMLUnitNG的安装，可以自动生成相应的测试代码对代码段进行测试。从测试样例可见，使用JUnit进行测试，测试强调了方法的鲁棒性。例如对整数范围内的最大值、最小值、0、空值及其组合都会进行相应测试。所以，在第四单元和今后的Java程序中，除了自主编写测试程序和测试用例外，我还学会了结合JMLUnitNG进行自动的程序测试。
  

五、课程收获

  
  一个学期的面向对象课程学习下来，发现自己真的长进了不少。纵观四个单元面向对象编程作业的完成过程，从臃肿的代码方式到后面较为抽象的设计实现，我的编程思维发生了不小的转变。
  
  在设计上，在对功能需求进行分析之后，带着“高内聚、低耦合”的思想，可以抽离出相应的类来均衡实现相应的功能，并使这些类相互交互来实现整个系统的功能。例如，第三单元中的作业是逐级递进的。这与一般用户的需求相近，每一次的功能是单调递增的，而且具备一定的继承性。这个系列作业，从PathContainer，到Graph再到RailwaySystem，很形象地描述了实际OOP开发中，一个功能模块的演化过程。从低层次抽象，逐步形成一个面向实际需求的模块。这对我今后步入工作岗位或科学研究都是很有帮助的。另外，每次做作业前应注意架构和设计，所有在设计上花费的时间都会在未来收到回报。不必着急开始动手编写代码，要事先考虑好图的结构用什么存储，最短路径用什么算法实现等等，此外还要考虑好结构的可扩展性。
  
  在测试上，除了会应用Python编写黑盒测试用例，还能够不断针对特殊点完善自己程序的鲁棒性。最后还学到了拥有JML规格后基于junit的自动化测试，来对程序进行逻辑验证。
  
  在程序质量上，除了鲁棒性的考虑更加完善外，程序容错率也有所提升。之前写代码不会考虑一些不可能的因素，现在编写会尽量将if-else或switch的每个分支写全面，再如对HashMap的查询尽量使用getOrDefault方法，而不去使用get方法。尽管在设计时会认为有些分支条件不可能被触发，但一个完整的、规格化的设计方式不但可以避免很多bug的出现，还能让自己和其它程序维护的人看起来清楚明了。
  

六、改进建议

  
  1、首先是大的教学方法上，面向对象课程和计算机组成课程的授课方法是有很大区别的。计算机组成课程的教师会对课下的编程作业做很多架构上的分析，老师带领所有同学一起思考如何架构会是最佳方式；而面向对象课程的老师则是课上带着大家一起讨论如何架构的时间有限，更多是让同学课下思考与讨论最合理、可延续性的架构方式。因为如果不能自己做出架构，就不会有真正的技术掌控力。这样的做法虽然让我走了不少弯路，比如某次作业由于架构不合理，需要在上一次作业的基础上重构代码；但也在一个学期下来培养了我高内聚、低耦合，面向对象的思维方法。可能是因为计算机组成是我们进入计算机专业后第一座大山，同学经验有限，需要老师更多带领，而OO课程的老师想培养我们自己探索、自己思考的能力。我无法确定地说，这两种教学方式哪一种更好，但是这个问题我想在这里提出来，供老师和各位同学思考讨论。
  
  2、其次，可能也是课程组考虑到了上一自然段所述的问题，同学们可能在自己思考探索后还是没有做到最佳的架构方式。在每个单元结束后，助教都会整理出几份推荐代码供同学们学习。由于这部分内容并非强制学习，且推荐的内容是上一个单元的作业，往往与当下手头的作业没有直接的关系，导致大部分同学无暇去看，或懒得去看。建议是这部分内容变成强制性学习内容，比如可以纳入到总结性博客作业中。
  
  3、此外，是课程指导书的下发。这一年OO课程的教学内容较前一年改变很大，所以有时指导书下发推迟或内容不完善也可以理解。但是我们希望能麻烦OO课程组对这一学期下来同学们提出的指导书的Bug和解释不充分的地方进行补充完善，能为下一届学习OO的同学提供更多便利。
  
  以上建议虽然语言上可能看似比较犀利，但是发自肺腑。我在一个学期的学习下来确实提升了自我，所以也由衷地希望这么课能越来越棒！
  
  总的来说，我认为从去年的课程内容再到今年，面向对象课程组的教学内容和方式在不断地完善和升华。也特别感谢助教们对于我们编程作业的细心解答。更要感谢吴际和荣文戈两位老师的教学，课程清楚明白，切中重点，培养了我面向对象的设计思维和设计方法。祝愿OO课程组越来越好。