自己学号：10061195 姓名：梁鸿
队友学号：10061161 姓名：宋晨希
队友的优点：
1、善于学习，在遇到新的问题的时候能很快找到相关的资料进行解决。
2、能较好的把握程序的整体部分，对于整个程序有着清晰的认识。
3、在写程序的时候十分认真。
队友的缺点：
不太容易注意或者找到一些小的错误。
结队编程的优点：
1、遇到不懂的问题时可以问队友，大家都不会就一起学，相互讨论效率比较高。
2、一些很小但是影响比较大的错误更容易被找出来，一个人会犯的错误两个人一起犯的概率小的多。
3、增加了交流，让写代码的过程不再单调。
4、可以更清楚的意识到自己的不足并且学习对方的优点。
结队编程的缺点：
1、两个人的想法可能会不一样，理解对方的想法并且接受需要一定的时间。
2、工程只有在两人同时有时间的时候才能正常进行，时间限制较大。
3、代码风格不统一时需要交流解释进行统一。
结队编程照片：
Information Hiding, interface design, loose coupling的定义及使用方法：
信息隐蔽指在设计和确定模块时，使得一个模块内包含信息(过程或数据)，对于不需要这些信息的其他模块来说，是不能访问的。在面向对象方法中，信息隐蔽是通过对象的封装性来实现的。信息隐蔽的概念与模块的独立性直接相关。
信息隐藏，接口定义，松耦合，使程序具有良好的封装性，便于扩展功能而不影响缘由的类
封装的一个主要的好处，就是增加软件代码的内聚性。通过增加内聚性，进而提高可复用性和可维护性。 信息隐藏的好处，正好和“封装”的好处相呼应。封装是为了提高内聚性；而信息隐藏是为了降低耦合性。通过降低耦合，一样可以达到提高可复用性、可维护性这2个目的。
具体来说在电梯调度里的有电梯，乘客，搭乘请求的接口，并将接口封装到 commons.cs 文件中，在program，elevator，loaders，passenger上就可以方便的使用，而在我们工 作的重点电梯调度算法（scheduler）上，恰当使用这些接口，继承拓展原来简单的 scheduler，同时在拓展原scheduler类的同时，我们也充分利用以上方法，拓展员初始化类 和QueueReq类，并将各种判断条件从主题函数run()中分离出来，方便以后修改复用，例如 ：IsAtTopFloor/IsAtBottomFloor 函数判断电梯调度边界条件，getTheNextStop定义了下一个需要停的位置，AddInReq来记录进入电梯的进入层，IsIn判断是不是上班情况。
契约式设计或者Design by Contract (DbC)是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的“契约”或者说“契约”是一种比喻，因为它和商业契约的情况有点类似。所谓契约，也就是合约，规定两个交互物件上的权利和责任。雇佣合同规定你的工作时数和你必须遵守的行为规则，作为公司则付你薪水，双双履行义务，双双受益。
一 前置条件（precondiction）：为了调用函数，必须为真的条件，在其违反时，函数决不调用，传递好数据时调用者的责任。
二 后置条件 （postcondion）：函数保证能做到的事情，函数完成式的状态，函数有这一事实表示它会结束，不会无休止的循环
三 类不变项（class invariant）：从调用者的角度来看，该条件总是为真，在函数的内部处理过程中，不变项可以为变，但在函数结束后，控制返回调用者时，不变项必须为真。来自百度百科
在这次结对编程中，由于我们是一起讨论来确实函数及其功能的，也仅仅修改了scheduler这一个类，所以对于接口部分的代码没有做变化。
契约设计的优点：
契约能使文档在使用、维护、变更时有更好的性能，对于使用都来说更容易保证程序设计与运行的一致性，可靠性更佳。
契约设计的缺点：
契约的限制比较大，在有改动的时候变更的部分会更多。
UML图：
我们算法中独到的地方：
在开始写之前，我们想了一些可能的算法。在与其他人交流以及在写程序的过程中，我们发现了许多在之前没有想到的问题。最开始我们想先简单修改一下bus的方法，然后再一步步改进，结果还没开始就结束了，因为我们的想法在让电梯来回动，然后在没有请求的地方不停就可以。在读代码的时候发现，如果电梯停在了一个楼层，电梯会开门等5秒钟。这是一个已经封装起来的电梯的类的方法，我们无法在调度过程中让一个电梯停在某层还不开门。如果我们一定要这样写，我们必然要在行动之前就决定要停在哪里，那就没有必要让电梯来回走了，只要去有需求的地方就可以。
电梯的算法就这样决定了，无人时找最近的请求，有人时响应同向并小于目标层的请求。这样的结果就是在电梯在运行结束后会停在任务结束时的位置，这对普通时间和下班时间是可以接受的，但是对于上班时间就有一些学浪费，因为上班时间人们进入电梯的位置大多数是在0层和1层，停在其它层会影响效率。于是我们又做了一点改进，直接针对上班情况：在进行简单的判断之后，如果认定当前状态是上班状态就执行以下命令：1、如果是闲置状态就回到1层。2、如果在闲置时有请求优先响应来自第0层和第1层的请求。至于为什么是第1层而不是第0层，这是在经过运行测试后发现停在第1层的效率要高于停在第0层的效率，其实际意义可能是1层相比0层更靠近中部。再次运行之后发现这样的处理能比原来的处理方法提高3%左右的效率。对于普通状态和下班状态没有能实现更好的方法。
