标签：设计 多线程 jpg 规划 may 慢慢 比较 没有 导致
===作业分析===
一、多线程电梯
1.结构分析
对于第一张图片，圈复杂性的问题，可能还是由于对于电梯运行状态和捎带等情况的条件判断逻辑不够清晰。另外，有些方法因为分支过多，仍然导致了方法的代码量比较大。很多情况下仍然是很难避免这类问题。也尝试过在最初做一些规划，但由于水平有限，并不能做出良好的设计，实际的方法设计或分支设计仍然是在写代码的过程中边写变设计，难免会有这种情况的发生，不过就目前的分析来看，情况并不严重，而且我相信可以通过将来的练习多加改善。
以上是这次作业的类图。自我感觉，由于前两次的电梯作业的铺垫，这次的类的设计较为良好。对于请求模拟器、调度器、电梯的设计基本与前两次作业类似，只不过是加入了线程机制。而printer则是用于统一管理文件输出的类，ElevatorQueue则是由于线程安全的原因设计的对于ArrayList的封装（因为只知道ArrayList，不知道别的）。
线程协作图，比较简单明了。首先主线程Main启动另外的线程。请求模拟器ReqSimulator作用是读取请求，放入ReqQueue中；调度器Scheduler则是从ReqQueue中取请求，满足生产者消费者模型。Scheduler将读取的请求分配给相应的电梯。
2.测试及bug分析
这次作业是这三次作业中写的最仔细的一个。但没想到最后还是出了差错。由于提交的一些疏漏，本来十分完善的程序在编译上出了问题，作业就这么无效了。算是白写了吧……
二、IFTTT
1.结构分析
这一次的结构比多线程电梯的结构要乱一些。其实在最初设计的时候就有点摸不着头绪，心里也想了几个不同的结构，不知道用哪一个好。最终还是采用了这个。主要内容是，触发器为Trigger类，由它产生四个子类，也就是作业中要求的四种触发器。因此，我的程序相当于每个触发器采用一个线程对象。记录detail和summay则是通过自己构造的SafeFile类来进行实现。
2.测试及bug分析
这一次作业的完整性较多线程电梯时差了很多。有一些功能不知道如何实现，线程安全也是按照自己的理解简单的布置了一下。总之这次作业写的时候最没有头绪。最终还是有很多公测点都没有过。很多没有通过的公测点都是对于一些无效的输入或者特殊情况没有考虑好。
三、出租车
1.结构分析
这次的结构，最初就是按照多线程电梯的代码照搬过来的，很多类都是这样，例如Reqsimulator、Req、ReqQueue、Scheduler等，当然在写代码的过程中，由于本次作业的内容还是与多线程电梯有一些区别，所以还是进行了一些功能上的改动，比如Scheduler类在本次作业的作用就大大减弱了。而请求类Req在本次我将它设定为了线程，这主要是为了实现三秒的抢单时间。
2.测试及bug分析
这一次在测试方面，基本没有被挑出bug。但是这次的很多代码还是不太好。由于时间紧迫，很多地方没有特别好地实现设计原则，之后的几次作业还要做出租车，所以我还是要加以改进。
四、另外的一些心得体会
这三次主要是集中在多线程的设计上进行的训练。首先，在多线程电梯时，初次接触多线程还是遇到了很多困难。一开始是根本无从下手的。通过研读课上ppt所给的例程，最后终于基本理解了多线程的基本机制。在这三次的作业中都进行了运用。不过对于很多线程之间的一些具体的交互，仍然是有一些疑点，今后还是要继续攻克。
而对于最糟糕的一次作业IFTTT，问题还是比较多，不过不是多线程的问题，而是代码本身设计与实现的问题。这种情况我认为实际上还是反映了自身程序设计的水平还是有限，需要慢慢提升。
标签：设计 多线程 jpg 规划 may 慢慢 比较 没有 导致
原文地址：https://www.cnblogs.com/ShiningLin/p/8982047.html
