pair work-Elevator Schedule

编程人员：周敏轩 192 周萱 149

1 有关结对编程的思考

结对编程技术是指两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法、同一段代码或同一组测试。通过这次的结对编程练习我结识了周敏轩同学，体验了结对编程这样一种新的编程方式。

在结对编程的过程中，对结对编程的体验总结如下：

结对编程的优点如下：

在独立设计、实现代码的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量便取决于水平较高的（周敏轩）那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，同时也省下很多以后修改、测试的时间。这样高质量的产出能够给程序员，尤其是能力较低的（我）那一位带来一些信心。而且，在结对编程的过程中两位程序员互相交流，相互学习传递经验，能够在结对编程的过程中学习到更多的东西。

但是结对编程也存在着一定的缺点：

结对编程的过程中，代码一直处于“复审”的过程，即不断地审核，提高设计和编码质量的过程。这样对于提高代码质量有很大的帮助，但是在互审的过程中也存在着一些问题：例如，复审的程序员对代码不及编写代码的程序员深入了解降低了复审的效果。而且，这次结对编程是随机分组的，我和周敏轩犇犇以前并不熟悉，这次结对编程的过程也会因为互相并不熟悉而产生一些缺少交流的问题。

结对编程队员的优缺点：

周敏轩同学有多年的C++编程经验，在一些编程的比赛上也获得了奖项。这样的光环在我看来无疑是需要90度仰望的。犇犇的编程经验是他很突出的一点，因为据他说，他对C#也不是很熟。这充分的体现了，犇犇的学习能力和对问题的分析，解决的能力。

而且，犇犇的性格很好，在编程的过程，我问过一些很低级的问题，犇犇会很耐心的解答。这应该可以算作犇犇的人格魅力了吧。

第三，犇犇很专心，也很敬业。在编写代码的时候犇犇可以看出来是很用心的，并没有一丝想要蒙混过关的想法。

第四，犇犇不逃选修。

要说缺点的话，就是，犇犇有点内向，（这也不能算是缺点吧）。

周萱同学优点：学习态度比较好，不懂就问；比较积极上进，在阅读了周犇犇的算法之后，自己经过思考也提出了自己的算法，并进行了实现。虽然效率不怎么样==；认真负责，工作效率高。

缺点：容易懈怠，不专心。

pictures：

2 有关Information Hiding, interface design, loose coupling

Information Hiding：在面向对象方法中Information Hiding是通过对象的封装实现的。隐藏对象的属性和实现细节，仅对外公开接口，控制在程序中属性的读和修改的访问级别；将抽象得到的数据和行为（或功能）相结合，形成一个有机的整体。

在程序设计过程中可以通过控制访问权限来实现。例如用private，public，protected修饰属性和方法。

interface design：interface design包括三个方面：

1 用户接口

用来说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。

2 外部接口

用来说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。

3 内部接口

用来说明本系统之内的各个系统元素之间的接口的安排

loose coupling：类与类之间的互相调用，这两个类之间就会有比较高的耦合程度，降低类与类之间的耦合程度，可以通过接口实现。

3 有关Design by Contract

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

在面向对象程序设计中一个类的函数提供了某种功能，那么它要：

1.期望所有调用它的客户模块都保证一定的进入条件：这就是函数的先验条件—客户的义务和供应商的权利，这样它就不用去处理不满足先验条件的情况。

2.保证退出时给出特定的属性：这就是函数的后验条件—供应商的义务，显然也是客户的权利。

3.在进入时假定，并在退出时保持一些特定的属性：不变式。

因此在进行Dbc的时候我们通常要考虑三个问题：

1.它期望的是什么？

2.它要保证的是什么？

3.它要保持的是什么？

DbC六大原则

原则1 区分命令和查询。查询返回一个结果，但不改变对象的可见性质。命令改变对象的状态，但不返回结果。（应当是不一定返回结果）

原则 2 将基本查询同派生查询分开。派生查询可以用基本查询来定义。

原则 3 针对每个派生查询，设定一个后验条件，使用一个或多个基本查询的结果来定义它。这样我们只要知道基本查询的值，也就能知道派生查询的值。

原则 4 对于每个命令都撰写一个后验条件，规定每个基本查询的值。结合“用基本查询定义派生查询”的原则，我们现在已经能够知道每个命令的全部可视效果。

原则 5 对于每个查询和命令，采用一个合适的先验条件。先验条件限定了客户调用查询和命令的时机。

原则 6 撰写不变式来定义对象的恒定特性。类是某种抽象的体现，应当将注意力集中在最重要的属性上，以帮助读者建立关于类抽象的正确概念模型。

4 uml图

5 有关UnitTest

好不容易弄清楚单元测试干什么的，但是许多方法因为都没设返回值，不知道怎么编写单元测试的代码，最后测试出来的结果就是：

虽说结果很挫，还是分析下吧。忽略那些没有通过的测试，整体的代码覆盖率简直就是惨不忍睹，不知道写了正确的测试代码后能不能提升一点。或者就是我写程序的习惯太差了吧，下次一定改进。

6 有关算法

算法概述：
对于每个电梯，建立一个List<dst>存放该电梯需要访问的楼层列表，dst类包含一个int和一个Direction参数，一个表示目标楼层，一个表示该请求的方向。该列表通过一个sortList()方法进行排序（根据电梯当前方向和楼层来确定List中元素的访问顺序）。
每次调用run()方法时，首先遍历所有电梯，调用gotoFirst()方法访问它们访问列表的首项，如果没有首项，根据当前客流情况（上下班之类的）添加一个目的地。
随后我们扫描当前请求列表中的请求，对于每个请求，我们扫描每个电梯，通过一个估价函数upValue()来确定当前请求插入后所产生的代价，然后选取代价最小的电梯，将该请求插入到访问列表中。然后调用sortList()方法进行排序。
 
算法关键：
排序算法sortList()的应该算是一个关键吧，排序要考虑当前方向和楼层，然后根据请求的方向和楼层来排访问列表，这里情况很多，所以代码量很大。另一个关键就是估价函数upvalue()，对于一个请求，扫描电梯的访问列表确定其所在位置，然后返回一个代价，这里找位置也不太容易实现，其实最后我也没有精确的找到这个位置，只是给出了一个大概的位置和估价。sortList()方法调试了我好久，重写了大概3次吧，因为如果稍微顺序错了，就会导致人上不了电梯，更诡异的还会直接把这个人给忽略掉。
 
 
独到之处:
首先，由于存在上下班高峰的情况，所以我开了3个int变量gotowork, gohome, sum来记录当前请求的上班数，下班数，以及总数（实时更新的），然后根据它们的比例来确定当前的状况。上班的话，没有任务的电梯都加入一个前往0层的任务，下班的话，没有任务的电梯分别分配到5，10，15，20层，如果随机情况就让电梯停在当前楼层。
独到之处我也不知道怎么讲，可能就是贪心的比较好吧。效率的话其实还是不错的，效率如下图：

	Bus	我们的算法
Passenger1.xml	307.05	62.7
Passenger2.xml	665.443	222.229
Passenger3.xml	942.943	319.847

如表所示，效率还是可以的。除了passenger3的数据可能不是很优（对比薛神算法的180来说）。不过其他两个的效率还是可以的。