本次结对编程由我和王熹完成，先发图片

结对编程我们之前从没接触过，关于优缺点书上是这样写的：

（1）在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作能有更强的解决问题的能力。

（2）对于开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。

（3）在企业管理层次上，结对能更有效地交流，相互学习和传递经验，能更好地处理人员流动。因为一个人的知识已被其他人共享。总之，如果运用得当，结对编程能得到更高的投入产出比（Return of Investment）。

具体情况应该分类讨论

若两人技术水平差别不大，则可以进行互相促进，一个人往往会忽略一些细节等，可以通过结对编程提高代码质量，同时，若两人擅长不同的方面，则可以进行更好的沟通和协调，互相取长补短，最终更容易达到较好的效果。

若两人水平差距较大，则一方面水平较高的人可以通过将军自己的思路帮助水平较低的人学习，而自己也能在讲述过程中发现设计的不足。

此外，对于工作效率的问题也是两方面的，两个人一起虽然可以减少单人容易走神等问题，但如果两人都比较爱玩，也容易同时转移话题，这样反而影响工作效率，而且很多人习惯独自工作，在他人在旁时可能提高效率，但也可能降低质量。

没有一个方法是通用和完美的，结对编程同样有很多不足

首先双方需要约定时间，不是很自由，容易耽误时间。

同样过程中很可能因为某一问题产生争执，或不赞同他人的编程习惯，设计方法等，若不能及时解决冲突，将会影响工作进程。

关于设计方法：信息隐藏，接口定义，松耦合。

这次的框架是这方面的很好的范例，下面进行一些分析

Information Hiding：In computer science, information hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed. The protection involves providing a stable interface which protects the remainder of the program from the implementation (the details that are most likely to change).

这次的电梯中的乘客，Schedular没有得到关于乘客的任何信息，关于乘客的方向，以及请求时间，乘客姓名以及体重等都没有提供给电梯调度模块，而且乘客也不由电梯调度程序控制，乘客与电梯相关的信息都被封装为Request发送给Scheduler，这是符合实际的。同时Scheduler由类厂初始化，Program类也无需知道Scheduler的具体实现。

Interface Design：

接口即是具体实现的抽象，可以方便的根据需要修改一部分的具体实现而无需修改接口，接口只定义了功能，是一个标准。实际过程中这也是非常常用的，上次的Individual Project中我们使用的ICompare接口就是一个常见的例子，.net框架定义了这个接口，用于比较两个元素，而默认的排序比较算法只并不知道具体的数据是什么样的，但是对于具体的数据，只要实现这一接口，就能用默认的算法进行排序，代码复用程度大大提高。本次作业框架中包括电梯，乘客等都定义为接口，而电梯的一些其他数据也进行了封装，这样可以方便的修改实现而无需修改接口。

Loose coupling：

In computing and systems design a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. The notion was introduced into organizational studies by Karl Weick. Sub-areas include the coupling of classes, interfaces, data, and services.即一个类对其他组件知道的越少越好，否则依赖项过多系统很难维护和重用。这里的类厂又是松耦合的一个很不错的示例以及各种的接口设计都是这样的思路。scheduler不关心具体的Elevator和Request的内容，甚至也不知道有passenger类，同样主程序也不关心具体的scheduler实现，这使得每个部分的独立性更强，更易维护。

Design by Contract：

优点：分开工作，每个开发人员只需关注自己所需实现的部分符合定义的规则，无需进行复杂的考虑。

缺点：要求接口必须先设计完整，否则后期发现用户需求改变需要更改接口时将非常麻烦。

UML图通过反向提取模型实现：

算法描述：

基本采用正常电梯的算法，分为以下几种情况：

若电梯为空且没有请求产生，若存在最近的一个楼层总请求数为每层平均请求数的两倍，即该楼层的请求概率大，则移动至该楼层，否则状态不变。

否则若当前停止且有外部方向请求，此时分两种情况，若当前层有请求则改变相应方向使乘客上电梯，否则找到同方向请求中的最短距离的请求并前进至该层。

若电梯正在运行中，则在同方向上找到内部乘客楼层请求和外部同方向请求的最小楼层，若电梯已满则不考虑外部请求，如果都没有，则寻找外部反方向请求并到达该层，若反方向请求也不存在，则电梯在最近的一层停止。

每次讲保存总请求数和各层请求数。

算法改进：由于要求平均时间最短，则可以在电梯在某一状态时进行估值，判断下一个行进方向，估值函数综合考虑请求数，方向和距离，这样在两边都有反向请求时若请求多的方向和电梯行进方向相反，也可能得到多个会得到更大的权重，这时电梯可放弃当前方向转而向权重大的方向前进。