结对编程作业博客，标题要长长长长长长

结对人员 张孝祖173，李雁南163

结对编程优缺点

优点

1俩人合作，不懂的问题可以讨论，不会的可以一起学习，对未知的任务会比较有信心！

2 俩个人四肢眼睛，代码的bug会容易检查发现！

3 增进我们的人际交往能力，交了一个新的朋友！

缺点

1 俩人代码风格存在差异，想法会有不统一的时候

2 分工不一定合适导致没有发挥各自的长处

3 俩人时间不同意会使工程延期

队友的优点

1.工作细心认真，负责任。

2.不会的问题虚心学习，有耐心，恒心。

3..思维敏捷，对于算法出现的问题总是有着其独到的见解；
缺点

比较懒惰。。。。。嘿嘿

看教科书和其它资料中关于 Information Hiding, interface design, loose coupling 的章节说明怎样利用这些好的设计方法。

信息隐蔽指在设计和确定模块时，使得一个模块内包含信息(过程或数据)，对于不 需要这些信息的其他模块来说，是不能访问的。在面向对象方法中，信息隐蔽是通过对象的封 装性来实现的。信息隐蔽的概念与模块的独立性直接相关。

信息隐藏，接口定义，松耦合，使程序具有良好的封装性，便于扩展功能而不影响缘由的类

封装的一个主要的好处，就是增加软件代码的内聚性。通过增加内聚性，进而提高可复用性和可维护性。 信息隐藏的好处，正好和“封装”的好处相呼应。封装是为了提高内聚性；而信息隐藏是为了降低耦合性。通过降低耦合，一样可以达到提高可复用性、可维护性这2个目的。

具体来说在电梯调度里的有电梯，乘客，搭乘请求的接口，并将接口封装到 commons.cs 文件中，在program，elevator，loaders，passenger上就可以方便的使用，而在我们工 作的重点电梯调度算法（scheduler）上，恰当使用这些接口，继承拓展原来简单的 scheduler，同时在拓展原scheduler类的同时，我们也充分利用以上方法，拓展员初始化类 和QueueReq类，并将各种判断条件从主题函数run()中分离出来，方便以后修改复用，例如 ：IsAtTopFloor/IsAtBottomFloor 函数判断电梯调度边界条件，LastScheduler定义最近调 度方案，尽可能减少重复代码。

 

看 Design by Contract, Code Contract 的内容:描述这些做法的优缺点, 说明你是如何把它们融入你的作业中的。

　契约式设计或者Design by Contract (DbC)是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的“契约”或者说“契约”是一种比喻，因为它和商业契约的情况有点类似。所谓契约，也就是合约，规定两个交互物件上的权利和责任。雇佣合同规定你的工作时数和你必须遵守的行为规则，作为公司则付你薪水，双双履行义务，双双受益。

一 前置条件（precondiction）：为了调用函数，必须为真的条件，在其违反时，函数决不调用，传递好数据时调用者的责任。 　

二 后置条件 （postcondion）：函数保证能做到的事情，函数完成式的状态，函数有这一事实表示它会结束，不会无休止的循环 　　

三 类不变项（class invariant）：从调用者的角度来看，该条件总是为真，在函数的内部处理过程中，不变项可以为变，但在函数结束后，控制返回调用者时，不变项必须为真。来自百度百科

在我们的工作当中，分工时就规定了俩个人负责的项目，一个写算法，一个完成代码的编写，因为代码是一个人写的，所以没有约定好的接口等等，但是其实俩人的分工约定也算是契约的一种。

契约式设计优点

契约能使文档更出色；契约是类特性的公开视图中的固有成分；
有着更可靠的文档，运行时要检查断言,以便保证制定的契约与程序的实际运行情况一致；

契约式设计缺点

契约过于死板，不容易让创意得到实现，也不容易添加新的功能，因为函数功能已经约定好。

UML图

 

 

我们的算法精华   
    之前我们也询问了其它小组的一些想法，经过讨论以后决定的算法是：就像日常所用的电梯一样，对于每一个电梯外的人来说，他们提出一个请求后，电梯内部会根据方向来判断让哪一个电梯去载，判定标准为是否有电梯的行进方向上有这一楼层，且行进方向与该乘客的方向一致，若无，则让未行进的电梯去完成这一任务。然而，在编程时，由于这一算法实现起来过于复杂，且还有许多的判定优先级需要去考虑，最终难产了。于是，现在的这个算法诞生了。
最后实现的算法是：为每个电梯都设置一个等待队列，对于每个电梯，进行如下操作。（1）在其静止时，若其等待队列有请求时，分4种情况讨论：1电梯在提出请求的楼层上方，请求方向向下，则去提出该方向请求的楼层中最近的一层；2 电梯在提出请求的楼层上方，请求方向向上，则去提出该方向请求的楼层中最低的一层；3 电梯在提出请求的楼层下方，请求方向向上，则去提出该方向请求的楼层中最近的一层；4 电梯在提出请求的楼层下方，请求方向向下，则去提出该方向请求的楼层中最高的一层。
（2）在其运行时，若是上行，若是中途经过的层中有请求，且方向一致（即上行），且仍有一人的余量（此处出于人道主义，取的是45KG，即最轻的重量，因为外面的人如果仅有45KG，取别的数字将会使得此人眼睁睁的看着电梯经过），则该层的上行请求将被接受，电梯到达该层将会停留；同理，当下行时，若是中途经过的层中有请求，且方向一致，且仍有一人的余量，则该层的下行请求将被接受，电梯到达该层将会停留。