pair work-Elevator Schedule附加题

[电梯调度算法的实现和测试] [附加题]

首先，我要感谢周敏轩同学和薛亚杰，吴渊渊小组。UI的编写是在两个小组成员的共同努力下完成的，希望在第二次结对编程中能够再一起对UI界面进行更新和完善。
UI编写人员

周敏轩 192

薛亚杰 193

另外，特别感谢毛宇大神对我们编写UI界面进行了细致入微的指导。。。

[附加题] 改进电梯调度的interface 设计, 让它更好地反映现实, 更能让学生练习算法, 更好地实现信息隐藏和信息共享。目前的设计有什么缺点, 你会如何改进它?

从笔者这个c#白加面向对象白的角度来说，这个电梯调度做的挺不错的，可以让一些对C#不太熟的同学（比如笔者）通过调用一些方法来实现调度。但在做的过程中，笔者也发现了一些问题：

在电梯调度时，需要通过ReqStopAt()这个方法，当一部电梯接到了来自电梯外的方向请求时，他通过该方法前往该楼层，但是按下该请求的乘客并不会这么轻易的走进电梯，因为方向可能不满足其条件，这是，我们需要额外判断一下方向改变电梯的HistoryDirection值来让这个乘客上来，这里我觉得就不太方便了，因为如果要实现一个比较复杂的代码是，往往加入一个方向判断和改变的条件就会让编写难度上升好几个难度，因此导致很多同学也许有很好的算法，但被这些繁琐的条件弄得不从下手。因此，笔者想出的改进方法就是为每个电梯类增加一个访问列表，然后电梯每次根据访问列表自动停在某层，并改变方向，这样同学们只要根据请求规划电梯的访问列表就可以了。

[附加题] 目前的这个测试程序只有命令行界面, 请给它设计UI界面, 显示乘客/电梯的运动, 并实现之。

这个就是我们设计的UI。目前只能显示电梯运行的情况，关于请求和乘客暂时还没有显示。（我能说乘客列表调不出来么？）

TT...向大神咨询了根据算法添加UI的方法...很简单果然..

同一解决方案中新建一个窗体,在winform中实现简单绘图,这里我一开始用tablepanel辅助绘图(方便对齐),但是后来实现的时候发现闪烁感太强,删掉后效果好了很多...

然后新开两个线程,一个跑电梯调度算法,另一个刷新画面,这里采用的时候将四部电梯的label不停的刷Location的方法,还不错.

[附加题] 阅读有关 MVC 和 MVVM 设计模式的文章。说明你写的电梯调度的UI /Algorithm/interface 如何实现了MVC 或MVVM 的算法。

MVC开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。

在编写UI的时候就用到了MVC的设计方法，首先我们要先搭建模型，然后设计界面，最后为每个部件添加代码（控制器）。这样做的好处有：

1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。

2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。

3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。

4. 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。

[附加题] 我们现在的题目是假设所有电梯到达所有的楼层。在现实生活中, 多部电梯到达的楼层都不一样。如果是这样 (例如3号电梯能到达10 – 20 层, 4 号电梯能到达5-15 层)，整个程序框架和你的电梯调度模块要做什么改变? 请说明你的改进意见

只需要在电梯类中只能加一个可访问楼层的列表，当请求向每个电梯发出时，判断该楼层是否能到。这里可能还需要判断下乘客上电梯后，所到楼层不能到达的情况，为passenger类增加一个退出电梯的方法，然后重新生成请求。这里笔者又想到可以为每个passenger增加一个可上电梯的列表，一开始都可上，一旦执行的退出电梯的方法，就将该电梯拉黑，不再向其发出请求。