同组人：潘学
依然是之前的观点，我认为结对编程会在项目正式开始编写之前花费更多的时间。在开始编程之前，我们都有等着对方开始做，我再开始的想法，于是把这个编程项目拖了很久才开始。但真正开始之后，我们由于相互过问对方的进度，反而感受到了压力，逼着自己更快地完成自己的任务，使自己再被问到时候可以不回尴尬，最好还能有一些超额完成来让自己小小的自豪一下。
我觉得我的优点在于我有耐心，可以灵活运用找到的资源，学习能力强。但我的缺点在于我编程能力较弱。我的队友潘学的优点在于他做事积极，对交给他的任务有责任心，可以细心地完成任务，缺点在于比较随性，有时不会按照计划时间完成任务。
信息隐蔽指在设计和确定模块时，使得一个模块内包含信息(过程或数据)，对于不 需要这些信息的其他模块来说，是不能访问的。在面向对象方法中，信息隐蔽是通过对象的封 装性来实现的。信息隐蔽的概念与模块的独立性直接相关。
信息隐藏，接口定义，松耦合，使程序具有良好的封装性，便于扩展功能而不影响原有的类
封装的一个主要的好处，就是增加软件代码的内聚性。通过增加内聚性，进而提高可复用性和可维护性。 信息隐藏的好处，正好和“封装”的好处相呼应。封装是为了提高内聚性；而信息隐藏是为了降低耦合性。通过降低耦合，一样可以达到提高可复用性、可维护性这2个目的。
具体来说在 电梯调度里的有电梯，乘客，搭乘请求的接口，并将接口封装到 commons.cs 文件中，在program，elevator，loaders，passenger上就可以方便的使用，而在我们工 作的重点电梯调度算法（scheduler）上，恰当使用这些接口，继承拓展原来简单的 scheduler，同时在拓展原scheduler类的同时，我们也充分利用以上方法，拓展员初始化类 和QueueReq类，并将各种判断条件从主题函数run()中分离出来，方便以后修改复用，例如 ：IsAtTopFloor/IsAtBottomFloor 函数判断电梯调度边界条件，LastScheduler定义最近调 度方案，尽可能减少重复代码。
契约式设计优点
契约能使文档更出色；契约是类特性的公开视图中的固有成分；
有着更可靠的文档，运行时要检查断言,以便保证制定的契约与程序的实际运行情况一致；
契约式设计缺点
契约过于死板，不容易让创意得到实现，也不容易添加新的功能，因为函数功能已经约定好。
我们的方案为每个电梯设置了一个目的地的列表，每个电梯优先去往列表最上的一个目的地。而这个列表的建立，由程序判断。（1） 在电梯静止时，若有新的目的地请求时，分4种情况讨论：1电梯在提出请求的楼层上方，请求方向向下，则去提出该方向请求的楼层中最近的一层；2 电梯在提出请求的楼层上方，请求方向向上，则去提出该方向请求的楼层中最低的一层；3 电梯在提出请求的楼层下方，请求方向向上，则去提出该方向请求的楼层中最近的一层；4 电梯在提出请求的楼层下方，请求方向向下，则去提出该方向请求的楼层中最高的一层。当没有新的请求时，电梯请求列表清空，并开往最下一层停留。
（2）在电梯运行时，若是上行，若是中途经过的层中有请求，且方
向一致（即上行），且仍有一人的余量，则该层的上行请求将被接受，电梯到达该层将会停留；同理，当下行时，若是中途经过的层中有请求，且方向一致，且仍有一人的余量，则该层的
下行请求将被接受，电梯到达该层将会停留。
