首先,在分组之前,我和室友周敏轩已经详细阅读了往届学长的博客,认为电梯调度这个项目应该先做UI会比较好一点,于是动手展开了UI的编写;但分组结果并没有如我们所愿,但我们依然共同进行了UI的编写,希望在第二次结对编程中能够再一起对UI界面进行更新和完善.

UI编写人员

 

周敏轩 192

薛亚杰 193

 

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

另外，也特别感谢同组队友周萱(149) 吴渊渊(177)对编写UI的支持..

 

 

[附加题] 改进电梯调度的interface 设计, 让它更好地反映现实, 更能让学生练习算法, 更好地实现信息隐藏和信息共享。目前的设计有什么缺点, 你会如何改进它?  Analyze the   API design, and propose a better API so that Scheduler can have more freedom   and students can do more realistic scheduling. 

 

..这个要吐槽的地方就太多了..

1.如果passenger到了电梯里面,就会发出一个我要到哪层的请求,可是,如果去哪层的按钮已经被按下了...他还有必要再发出这个请求么..这个缺陷就会导致其实我可以根据计数来判断此时是否是上班高峰..算作弊?(这一点参考了学长谭传奇的想法)

2.api有的地方定义的很差啊...比如莫名其妙的出来个10.0什么的常数搞的一头雾水的...完全可以用elev.floorHeight来代替好么...

3.scheduler类中能获得的东西还是太少...我判断个请求都那么麻烦...完全可以在这个类中把Request请求定义成passengerRequest类好么...这样写起来就简单多了...

4.题目要求了电梯有passenger limit,有人数限制,可是在这份API里面根本找不到关于电梯人数的属性....好挫.

 

[附加题] 目前的这个测试程序只有命令行界面, 请给它设计UI界面, 显示乘客/电梯的运动, 并实现之。Implement a UI to show   how people/elevator moves  (write  a  blog to show your code   and UI)

 

......待我有了时间,老师等我可好!

 

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

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

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

 

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

 

 

呵呵.
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用于组织代码用一种业务逻辑和数据显示分离的方法，这个方法的假设前提是如果业务逻辑被聚集到一个部件里面，而且界面和用户围绕数据的交互能被改进和个性化定制而不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

 

实现起来很轻松啊...winform开发大体流程不都是这样么...我在winform中添加控件,这叫模型;在winform或者代码中调整窗体,调整布局,这叫视图;然后添加事件响应,完成程序逻辑流程,这叫控制器...

 

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

 

首先是电梯模块自然要限定对应电梯的限制楼层

然后电梯调度模块将乘客的我要上电梯请求压入之后,就要判断能否完成乘客的到哪层的请求了,如果不能满足,我们就把他踢出电梯...(呵呵呵),只能说这个乘客真傻,明明不能到哪层还要按下按钮.

所以说,如果电梯的运行方向有限制,那么必然需要在电梯外部,就要让乘客知道,这部电梯能够到哪些楼层,

这就势必更改我们调度模块的接口,传入完整的用户请求,来判断应该用哪部电梯来响应用户请求.