OO第二阶段做业总结

第五次做业：

        设计策略：

         本次做业设计的基本思路是按照指导书所给的推荐方法来完成的，即共用对象为队列盘，线程有电梯、调度器、以及扫描器，扫描器将控制台输入的有效指令加入到队列盘中，调度器依据指导书的原则分配任务给电梯，而后电梯将其一条条执行。在电梯的类中，加入了一个小队列，即电梯依次须要完成的任务。在同步控制中，对队列盘对象加锁，在某一线程使用时，其余线程没法更改，可是能够访问。这样存在一些时间上不一样步的问题，致使了一些bug的出现。

         度量：

         类图：

         本次的类图较为简单，因为实际使用的类并非不少，List类为扫描器，scheduler类为调度器，Elevator类为电梯，因为是三个电梯同时运行，所以实例化了三个电梯来同时运行。此次做业实现的好处在于思路简单，而且各种间的关系明确，易于在后续的找bug工做中提供帮助。可是缺点在于，类中只有run（）方法，代码的可读性太差，没有将各个工做模块化，所有工做塞在一块儿显得臃肿，而且代码复杂度极高，致使一些没必要要的问题出现。

         Metrics度量图：

         第一行的红色标记，代表了本次做业中，我对从控制台读取有效命令的方法部分模块复杂度过于复杂，而且嵌套深度也过深，这在第三行中也代表了出来。这依旧是由于，我在处理控制台的输入时，将正则判断也加入了这个模块，这致使了一个方法承担了许多任务和工做，所以让该模块的复杂度直线上升。而且对一条输入进行了屡次正则匹配，也直接致使了模块代码的复杂度和嵌套程度加深。对代码的优化和提炼作得还不够。

         分析本身程序的bug和不足：

         本次做业出现了两个bug，一个是因为没有使用继承机制，直接使用了之前的调度器和调度方法。事实证实，偷懒是没有好处的，测试者真的很细心，这样都能发现我用了之前的调度器。另外一个bug是若是最后一条命令是（#ER,1,1），个人程序就会crash，这依然是使用以前的调度方法的问题。还有一个bug测试者并未发现，在个人设计中，调度和扫描只能交替进行，这是因为对同步控制错误致使的。虽然没被发现，可是若是不及时改正，对接下来的其余做业一定会形成影响。此次做业仍是存在许多的不足，某个方法依然显得臃肿复杂，模块化和可读性程度都极差。对线程的同步控制也是作得不够完美，在调度上也存在一些问题，致使了程序crash。

 

第六次做业：

         设计策略：

         此次做业是实现对文件的监控和管理，明白ifttt原理。虽然老师一直说此次做业很简单，可是我以为一直写到深夜的应该不止我一我的。此次做业最大的难点就是，须要本身先自学java里对文件的操做怎么描述。这就花去了我许多时间。其实此次的做业难点在于架构，基本方面在于，扫描器扫描控制台的输入，读取文件的路径，监控内容等。在文件通过相应的操做后，可以做出对应的响应。而且须要写一个类，让测试者可以操做目标文件。个人策略就是每两秒扫描一次目标文件所在的文件夹，而后判断是否作出了监控器监控的动做，若是出现了，就执行须要执行的输出。按照指导书的要求，判断各个操做是否出现。

         度量：

         类图：

         其中List类是扫描器，负责处理控制台的输入。monitor类是监控器，也就是程序的主体，负责判断各个监控器的内容是否出现。detail记录了文件或文件夹的前后名臣，前后路径，前后大小和前后最后修改时间，而且输出到指定位置。summary类记录了监控器监控内容发生的次数，而且输出到指定位置。filevisit类是提供给测试者操做文件的另外线程。此次的优势在于我将detail和summary另起一类，让各个变量间独立，使结构更加清晰明了，输出到文件就不易于犯错。缺点在于须要在monitor中调用这两个实例化对象，会形成代码量变大以及monitor类中的变量增多，易读性就大大下降了。

         Metrics度量图：

         根据此次的metrcs度量图，能够看到已经没有红色的字体出现了。可是模块复杂度最高的仍是个人扫描器对控制台输入的部分，因为此次对输入格式并未做要求，所以在正则匹配上就没有那么多的工做量，所以没有形成模块的过于复杂。嵌套程度最深的是个人监控器类的监控方法，因为调用了不少其余方法来监控文件，因此嵌套程度最深。此次对各个模块代码的优化和简练仍是作得比较满意，模块化的程度也较高，并无预料中出现过于复杂化的模块的出现。

         分析本身的bug和不足：

         此次做业的bug存在不少，主要缘由是对recover要求处理不到位，对这个要求的并无去测试，只是完成了基本代码，可是在本身测试的时候并无考虑这个状况，所以就直接交上去了。而后错了一堆bug，才发现对recover，也就是将文件还原的操做是错误的，有时候程序还会不响应。后来在检查过程当中才发现执行recover操做时，没有记录更改前目标文件的路径和名称，只是将文件的位置改变了而已，由此形成了极大的失误。还有一个比较严重的bug是没有设计好多个监控内容的状况，若是监控多个目标文件，时间上会不一样步，致使输出到detail的最后修改时间错误。这是因为同步控制作得很差致使的。

 

第七次做业：

         设计策略：

         此次做业要求完成一个基本出租车功能的程序。基本方法在于，由扫描器扫描控制台乘客的目的地和所在地，而后由调度器调度附近符合要求的出租车去接送乘客。本次做业的难点我认为在于去完成最短路径的寻找，虽然由GUI提供的方法可以稍微魔改一下去找到最短路径，可是会花费大概3~4秒的时间，初始化时间太长我以为不太合理。就想到了数据结构使用的链表方法，使用了一个差很少的方法来查找最短路径，事实证实效果还不错。在程序实现时也直接引用了GUI的方法，让程序可以可视化。另外一个难点在于圈出4*4区域，让进入的出租车可以响应。

         度量：

         类图：

         此次须要完成的类有不少，所以看上去结构比较复杂。这是主要的缺点。而且能够看到各种之间的互相调用不少，致使了程序的嵌套程度很深。可是结构上的复杂必然就会有思想上的简单。Dis类用来计算两点间的距离。map类用来从文件中读取地图。scan类即从控制台读取乘客的需求。queue类即等待对列。taxi类便是出租车类。各自处理各自须要实现的功能，不会互相影响，而且可读性极高，后续的debug工做容易进行，这也是本次做业没有被找出bug的缘由之一吧。

         metics度量：

         第一行所指出的最复杂的模块是指导书所给的GUI模块中的让地图显示出来的部分。因为地图一直须要刷新，这是理所应当的。而后第三行，嵌套程度最深的又是个人扫描器的读取输入的函数。此次做业我对程序的优化和简练应该是作得比较好的，多是因为这个线程须要一直从控制台读取有效输入致使的，这个线程在设计上是须要一直运行的，由于须要不断的接受乘客的请求。这是理所应当的。

         分析本身的bug和不足：

         此次做业在互测阶段并无被找出bug来，多是测试者没有发现，可是我本身在设计中有个缺陷，这也是我交上去做业的一瞬间才想起来的。若是控制台同时输入两个或两个以上的乘客请求，个人程序只会响应其中的一个。另外一个不足在于，对于指导书提到的4*4区域，若是出租车一开始在该区域，但以后驶出区域后，应当是加入抢单队列的，可是我没有 处理这个出租车。虽然侥幸没被测试出来，可是确实存在这些小问题。必须在下次做业以前改进。

 

心得体会：

         这三次做业据老师说已是全部做业中比较难的了，但愿如此吧。可以活过第二阶段尚未无效做业已是万幸，但愿之后也不要有无效做业出现吧。而后就是努力完善本身的程序吧，既然不喜欢给别人找错，那就让本身的程序变得更无懈可击就行了。