OO第二次博客作业

OO第二次博客作业

1.多线程协同与同步控制分析

　　第5、6、7次作业的多线程协同与同步控制基本设计思路相同，基本都是由主线程、读入处理线程、以及主要功能线程组成，不同线程之间通过synchronized同步锁来避免多线程的冲突问题。

2.每次作业分析

第5次作业：

度量图：

 

类图

　　这次作业中，依然是负责根据输入指令改变电梯状态、运行电梯并负责输出的run方法占用的资源最多。而除此之外，由于没有采用阻塞，也就是wait()的方法，而使用了while(true)一直扫描（while中会睡眠很短的时间）直到能获取锁的方式，运行时占用的资源较多。由于继承了前几次电梯作业较为成熟的实现方式，所以运行时基本不会出现问题。

　　公测时被发现的BUG有两个，一是在报错某一种非法指令时，多输出了一个中括号。。纯粹由于自己粗心大意出现的问题，也感谢互测的同学细心检查，帮我发现了这个问题。第二个问题是在同质指令输出时会报一个空指针错误，在检查代码后，发现这是在构造器中偷懒没有写this.造成的问题。。在构造器中，传入的对象名与私有属性名相同时，如果偷懒直接写a = a;在有时会出现这样的问题。

　　而我负责测试的同学程序在我与我周围同学的电脑上并不能运行。。只有在某一位助教的电脑上可以运行，咨询老师后，由助教进行了公测，我来填写结果（感谢助教的帮助。。）。不过该位同学实现的功能极其有限，公测中都有许多错误的点，并且输入END并不会结束程序。希望这位同学能继续加油，早日走出苦海。

第六次作业

度量图：

 

 类图

　　由于多线程的多线程设计思路与前几次作业相同，所以占用资源最多的依然是负责实现主要功能的大方法run。这种设计优点在于设计思路简单，实现起来顺手，但由于线程的run方法中要负责实现要求的各种功能，往往占用了较多的资源。

　　互测时，由于这次测试的种种不方便性，并且由于写程序测试有较大的复杂度与工作量，大部分同学都选择较为简单的测试方式，即通过编写者提供的测试线程进行一些简单测试。所以这次测试中，我与我测试的同学都没有发现什么BUG。

第七次作业

度量图：

类图：

　　由度量图可以看到，这一次的多线程较为均衡，没有出现标红的方法，其中占用资源最多的是GUI中自带的readmap，读入地图的方法。这次的多线程注意点和前几次相同，要注意在读入某个对象的状态并进行相应判断，到给出对该对象的指令这段期间，有没有其他线程会改变这个对象的状态。

　　由于这是第一次多线程出租车，并且提供了GUI类，其中包含了bfs等实用方法，所以在实现上其实并不难，尤其是在出租车运行的规则较为简单的情况下。所以在互测中，我拿到的同学的程序运行良好，除了所有输出都在同一个文件中，对测试者可以说极其不友好外，就是在输入错误指令、同质指令时没有任何报错提示，这一点小小的瑕疵了。而我的程序也很幸运没有被报任何BUG，感谢测试的同学网开一面。

心得

　　随着多线程作业的不断推进，我逐渐意识到了wait、notify设计方法的优越性，并逐渐习惯了多线程各种玄学的BUG与极其不方便的DEBUG方式。最后，呼吁各位一起努力在OO第一线的同学们：虽然没有把输出写的明明白白、一目了然的义务，但也恳请各位同学们在写输出的时候为测试者多考虑一点点，毕竟每个人自己也都将作为测试者测试其他同学的程序，而一个一目了然、清清楚楚的输出也将为测试者带来良好的心情，也许这一点点的好心情就会成为测试者少报几个BUG的动机也说不定呢？

 

转载于:https://www.cnblogs.com/kirito12138/p/8977679.html