OO 5-7次作业总结

     又是三次OO作业，晚睡已经成为了习惯。回顾这三次作业的设计完成过程，自从走进Java多线程的世界，从三部电梯到IFTTT再到出租车，每次都是不同的体验，一方面感慨谜一样的多线程，一方面也意识到自己十分浅薄的功底。总得来说，收获很多，再回顾第一阶段的学习，这个阶段更加注重设计层面的学习，同时，也需要了解掌握一些基本原理才能更好地对程序进行剖析从而写出性能较好的代码来。以下，将对三次作业进行反思和总结：

三部电梯

尽管之前已经写过部分的电梯系列作业，但本次是基于多线程进行设计，所以首先认真学习了Java多线程编程的有关知识，紧接着分析本次作业的需求开始进行设计，即尽可能的像现实世界靠拢来实现同步化的电梯运行系统：一方面是三部电梯的正常运行，一方面是对乘客请求的处理，这中间需要一个调度器来进行任务的分配和协调，同时，它们又共享一个“托盘”，即请求队列。那么基于此，需要采用类方法实现“托盘”，采用线程机制来实现调度器、电梯和请求模拟器：请求模拟器将有效的输入请求及时填充到“托盘”当中；调度器不断扫描队列来调度请求，这个过程需要得到3部电梯的运行状态，进而将具体的调度请求传达给相应的电梯去执行；电梯从调度器获得请求，同时借助其内部的搭载队列来进行自身状态的改变更新，进而完成对请求的处理。在线程安全设计这一块，由于以上三者共享一个“托盘”，在具体实现过程中采取生产者—消费者模式来维护共享数据“托盘”的安全。

以下是这次作业的类图和度量：

                                            

    从上图可以看出，基于线程设计的调度器、电梯和请求模拟器均承载了太多的任务，并且由于当时贪图省事前期没有好好规划，使用了大量的循环判断If-else语句，尤其是调度器，类的均衡性做的不够好。除此，可能是初次接触多线程，再加上还有些面向过程的思维，具体的较好实现设计还是没有真正掌握，从而设计出一个不尽如人意的程序。

    关于本次作业的bug问题，我的程序出现的问题主要是部分与运动量和捎带有关的请求判断有些失误，其次是时间上的输出格式有些问题。想着重说一下拿到的互测程序，整体完成很好，无论是设计思路还是代码风格等等方面，可以说是到目前为止的互测程序中我见过的最好的一个了，也是对我影响最大的一个，我从他的程序中学习了很多，最深有感触的是他的代码十分简洁抽象，测试完公测加一些设计的小样例之后依旧无懈可击，于是我开始尝试读他的代码，可惜一开始我发现我连读都读不懂，因为太简洁抽象了。。。在这方面的收获对我后面的编程作业起了很大的影响，一方面在类的设计中让我学会去更好地将一些功能抽象出来完成，改变了我那“臃肿”的程序面貌，一方面让我学习到如何更好地进行类与类之间的交互设计。

 

IFTTT

如果说3部电梯带我走进多线程的世界，IFTTT则让我迷失其中。这次作业现在回想起来（如果只看测试的话）感觉Readme本身可能比程序更重要，很多地方都是readme,所以整个设计过程大体功能框架基于指导书而建立，其他的则是按照自己的想法来。可以明确的功能要求是，在一定监控范围内，对监控对象设置相应监控作业，一旦触发相应触发器则执行相应任务，并判断是否继续进行监控。从上述的叙述来看，我的设计思路就是一个监控作业一个线程，而非将具有相同触发器的监控作业放在一起处理，即首先构造好4个触发器—监控类，其中，利用快照进行分析对比，然后针对不同的监控对象（文件？目录？）进行不同的操作来判断是否触发，那么，基于这4个类，就可以从输入的监控作业来完成对监控对象的分配，并启动相应线程完成监控，同时有关于记载输出信息的线程在一开始就启动，当满足触发条件时，就会执行相应的输出任务。以下是本次作业的度量和类图：

                                                           　　　　　　　　       　　　　　　　　　　

                                                                                                              

    从上图可以看出，除了输入处理这一块，包含rename和path-changed的监控作业也较为复杂，相应的设计实现有些繁琐，，当时也是偷懒并没有依据功能进行分类整合，于是就用了很多的分支判断语句。本次作业由于涉及文件操作，在编码过程中用Safefile将File的部分功能重新包装，来避免文件类方法使用时存在的安全隐患。

    关于这次作业的bug问题，我的程序没有被测试，我拿到的程序部分类的实现有些对应不上，看了下他提交的时间可能是交错了某些版本吧，并且Readme写的模棱两可，在测试过程中给我造成了很大的困扰。他的设计思路正好与我的不同，是将具有相同触发器的监控作业放在一个相应的线程里处理，该线程有一个队列来记录监控对象，出现的问题主要是对目录的监控不够完善，其他方面做的还行。

 

出租车

   这是出租车系列的第一次作业，主要是将整个打车服务看成一个系统，考虑其与外部环境的交互设计，即出租车和乘客。系统的基本属性包括80x80的网状道路图，100辆出租车，其功能要求支持不低于300条的用户请求处理。整个线程设计考虑的是100辆出租车100个线程，在一开始的时候就启动，类方法主要是出租车的状态转化和具体运行；然后一个输入请求一个线程，完成对该请求的响应处理，主要包括模拟3s抢单窗口，记录满足条件（4x4区域内&WFS状态）的出租车信息，待窗口关闭完成配单或给出无车响应提示，并改变出租车相应属性来实现状态转换，然后线程结束。总体的设计思路就是：读取请求，启动请求线程（其中包括抢单配单），在出租车这一方面则是如果接单则依据请求来完成接送客人的过程，否则就执行其他相应的状态转化操作。值得注意的是，在配单时应该再次check出租车状态信息避免“一车多服务”的情况发生。以下是本次作业的度量和类图：

            　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

       这次作业最大的问题就是，可能因为一个请求一个线程，在实际的运行过程中有时会很卡，在后续的出租车系列作业中，将考虑优化这一块的设计。本次作业在前期准备时有认真考虑将代码尽量写的精简一些，但输入处理和出租车随机运行这一块的处理写着写着又for循环加If-else一条线走下来了。除此，其他方面较为满意。

      本次作业我的bug主要是一部分距离计算直接采用两点间距离进行计算，也是很粗心大意。拿到的互测程序完成情况挺好，格式方面的一个小细节忘了处理，功能测试没有问题。   

 

心得体会

     OO课程到此，已经完成了第二阶段的学习，比起第一阶段对一些基础知识的了解，本阶段的学习感觉像是进入了一个全新的世界，更注重设计，更追求性能，所教授的理论知识大多也都是广而泛的大词，比如说出租车一节的设计原则，乍一看感觉懂了，自己的设计也满足了，但其实其内涵精髓部分并没有很好的掌握，还是得认真实践、慢慢摸索才能真正领悟。在每次作业的完成过程中虽然有点痛苦，结果有时也还很不尽如人意，但是经历过后就会有新的学习收获，这个收获一方面来源于自己实践感悟得到的，一方面是源于学习他人，对我来说，由于我本身编程经历较少，这方面的功底很浅，很多地方做得也不是很符合规范，当拿到一个很优秀的互测程序时（比如那个多线程电梯程序），对我后续学习的影响很大。在此，也想建议课程组可以考虑在每次作业完成评判之后，推荐一两个优秀的程序设计进行分享学习，通过了解学习他们的设计思路，代码风格等等，一方面可以加深对理论知识的理解，一方面也可以对比发现自己的不足，从而在后续的编程中尽可能地去改善。