第二次作业的结对编程项目：电梯调度系统

结对编程小组成员：吴煜10061149    全风楠10061186

这次的作业与个人项目不同，不是从头写一个新的程序，而是在一个已有的程序之上做修改然后实现新的功能。

首先简单介绍一下项目：

　　一个模拟电梯的调度系统，四个电梯，从建筑物的底层（0层）到20层之间运送乘客，每部电梯都有人数与重量限制等等比较多的小要求，比较贴近实际。

　　我们要实现的目标就是多人在不同的楼层需要乘电梯去不同的目标楼层，怎样快速准确地将乘客送到目标楼层的算法。和第一次作业一样，准确是第一要求，其次再是速度。

　　给出的基本代码是一个类似“BUS”的程序，也就是电梯相当于公共汽车在每一楼层停一段时间让乘客出电梯。显然这样能够准确地将客户送到目标楼层，但是时间代价却很大。所以我们要改进的就是对每一位乘客来说“等待时间”最小。

　　我们的算法实现的基本思想是：在某一楼层的客户发出指令，电梯在接收指令时候将外部指令排个序，所有离客户最近的电梯到达，并且注意到上行和下行的区别。再者若是人数已经超出电梯限制，则第二近的电梯到达继续载人，依此类推。进入电梯的乘客发出不同的内部指令，确定不同的目标楼层。然后电梯在到达最远目标楼层的途中让其他乘客分别在自己的楼层出电梯。我们把其中一部电梯改成了BUS形式，一部每层都停的电梯与只听指令的电梯哪一个更快些并不一定，比如说要到楼上两层的话或许只听指令的电梯到达时还有要去楼下的指令，所以会和目标楼层距离更远，而BUS虽然说会在楼上一层时停一下，但也是直奔目标而去的，没有多浪费额外的时间。

　　此算法的UML图如下：

　　源代码就不往上贴了，程序具体实现与自然语言描述必定会有一定的差距，工程已上传到TFS。关于ASE方法，之前没有学习过，在这里做了一点总结：

　　信息隐蔽：类的成员变量的可见性统一成private，并设计相应的属性。

　　接口设计：设计接口是尽量细化，功能追去单一，不要设计功能臃肿的接口方法。

　　松散耦合：在一个系统中使各组件在最小的可行范围内彼此依赖，尽量限制类和类之间互相连接。

　　契约式设计：在调用方法前保证初始条件的正确性。

　　两周的结对编程很快结束了，现在再来说一下结对编程的相关感想。

　　之前没有这样做过，学习C语言和数据结构时都是自己写自己的程序，向大牛们请教也仅仅是思想的学习，具体码代码还是个人工作。现在两人一组结对编程，虽说有些不习惯，但还是有一定心得感想。结对编程有不少的优点：（1）能够将两个人的优势很好地结合起来；比如说一人擅长算法设计，另一人擅长数据结构实现，就可以很好地互补；（2）可以大大节省时间；比如说有一个功能实现方法两人都不是很了解，就可以一人先留住这个接口，继续写其他功能，另一人查资料以了解所需学习的功能，这样就能够不耽误工程进程并学到新东西，相当于开一个多线程~（3）可以调动积极性，提高两人的学习效率；之前的自己编程序的经验告诉我们，一人在对着满眼的代码时很容易疲劳，而且很难靠自己一直保持着高昂的斗志与热情一直在战斗，很容易把工程放下去做别的东西。两个人一起时就能够很好地相互鼓励相互促进，学习新东西也很快，更调动了积极性，逐渐形成良性循环。当然，凡事皆有利弊。结对编程目前发现的一个缺点就是，在同一个功能实现上，两人讨论出的算法虽说是确定的，但是实现上两人的意见往往不同，而且也比较难说服对方放弃自己的尝试。这样往往会两个方法都试一下，而且最后得到的结果也不会有很大的不同，这样就在一定程度上耽误了进程的流畅性，当然也能够在两次尝试中得到更好地改进，但并不是每次都能够有效果。归根结底，还是要在算法和数据结构的修炼上多下功夫，若两个人都能够想到最快的方法，不也就不会起争端了嘛~

结对编程上图：