OO第二单元博客总结

(1)  从多线程的协同和同步控制方面，分析和总结自己三次作业的设计策略

 

第一次作业设计策略：

第一次作业仅要求一部电梯，我采用的策略是生产者—消费者的模式，生厂者是输入乘客信息，消费者则是电梯，生产者和消费者之间有一个缓冲托盘。首先，生产者收到乘客信息后把请求传给托盘，然后电梯则查看托盘中是否有请求，有请求则从托盘中获取一个请求，按照这个请求进行楼层变换，每到一个楼层，查看是否有可以捎带或者下电梯的乘客。

 

第二次作业设计策略：

第二次作业要求实现多部电梯，但总体布局上和上次作业策略相同，仍采用生产者—消费者模式，但是这次是多个消费者。出现多部电梯就会出现电梯抢人的可能，为防止出现同步控制的问题，我在电梯处于等待状态时需要从托盘取请求，该请求乘客暂时还没有进入电梯，但必须把该乘客从托盘中移除放入电梯的一个缓存中，等到达乘客所在楼层后，把乘客从缓存中加入到电梯的乘客队列中去。

 

第三次作业设计策略：

第三次作业有多部电梯，且电梯存在动态添加，电梯的类型也不同。我在总体布局上仍采用生产者—消费者模式，生产者消费者不变，但是生产者的请求可能会产生消费者，故我设计了一个电梯池，用来存放电梯线程，该电梯池是非线程的，仅接受生产者的电梯加入请求。对于电梯类，我利用工厂模式，先设立了一个电梯总类，包含了电梯的基本方法和参数，然后不同的电梯类型继承至电梯总类，通过重写方法等来制定不同电梯的行为。

 

总的来说，我三次作业都采用生产者—消费者模式，我把电梯的调度策略全部封装在了电梯类的内部，这样就不需要单独的调度器来调度策略，每个电梯只需要按照自己的调度策略运行即可，只要对托盘进行上锁，就能很好保证线程交互之间的安全问题。

 

(2)  从功能设计和性能设计的平衡方面，更细和总结自己第三次作业架构设计的可扩展性。

第三次作业我把不同类型的电梯继承自一个电梯总类，这样就可以避免很多相同方法的重复书写，如果后续还有新的类型的电梯加入，我们也可以再写一个电梯子类，规定新的电梯类型的调度策略，这可以看做是电梯类型的一种扩展。

另外，第三次作业要实现动态的加入电梯线程，于是我构建了一个线程池类来存放和控制电梯线程，后续如果出现移除某个电梯的请求，我就可以将请求传入线程池，利用线程池将该电梯线程进行终止和移除，这可以看做是电梯数目动态变化的一种扩展。

 

(3)  基于度量分析自己的程序结构

第一次作业UML图：

 

 类之间依赖度分析：

 

 

 

第二次作业UML图：

 

 类之间依赖度分析：

 

 

 

第三次作业UML图：

 

 

 类之间的依赖度：

 

 

(4)  分析自己程序的bug

自己在三次作业中出现的bug主要分为3类，一类是自己手误敲出来的bug，这类不提，但需要多注意，一类是调度策略的考虑不周全，忽略某些特殊情况，会产生诸如死等，只进不出，出两次等bug，最后一类则是RTL类bug，很多时候出现RTL并不是电梯无法在规定时间内运送完乘客，而是电梯线程无法终止，尤其是第三次作业的转乘问题，很容易出现电梯提前终止的情况。

 

(5)  分析自己发现别人程序bug所采用的策略

手动测试+结构化测试

 

(6)  心得体会

本单元的作业主要是线程相关的电梯调度，电梯调度是一个挺有意思的题目，符合生活实际，还能加深我们对于多线程的理解，我个人觉得选题真的很不错。另外，线程确实打开了编程的新天地，也见识到了多线程的强大。本单元重点还是要关注多线程间的交互问题，线程安全是重中之重。