Pair Project：黄明源11061186 and 刘昊岩11061156

　　Pair project members：黄明源11061186 ，刘昊岩11061156 

　　

---

 

　　两周时间，工程下午刚刚结束，现做一些总结。

　　在现有工程基础上修改schedule 包下方法，主要思想是，也就是关键所在：电梯停的时候判断往哪里走，走的过程中顺路带人，电梯里有人先满足里面人的需求（就是直到把里面人送干净），然后回到电梯停的状态。主要代码框架如下（列个框架应该没问题吧）：

        public void Run()  //scan the request and make correct decision to control elevator;
        {
            foreach (IElevator elev in _Elevators)
            {
                if (elev.CurrentStatus.CurrentDirection == Direction.No)
                    RunNewReq(elev); //电梯没动，搜索新请求
                else
                    PickInTheWay(elev);      //电梯正在动，顺路带人
            }
            return;   
        }

　　判断电梯当前是否运行，如果运行，执行PickInTheWay()方法，否则执行RunNewReq()方法。前者作用是在电梯运行中，把路过楼层与电梯当前运行方向有相同需求的乘客拉上来（语言表达能力有限啊= =），后者是电梯不动时候搜索新的乘客请求，这里又分为有乘客和没有乘客情况。有乘客时候，先满足内部需求，电梯运行方向与内部需求方向相同，没有乘客时候，进行一个判断（难以表达清楚，详见代码= =）

　　单元测试如下：

　　　　

　　最后运行结果不是十分理想，不过比bus要好点~~主要缺陷是没有进行上下班高峰判断，曾经加入判断后有死循环和效率更慢情况出现，目前还没有好的算法，现在正与其他Pair进行交流。

　　最后把UML类图列出如下：

　

---

　

　　现在说下结对编程的感受，这是第一次做结队编程，感觉十分新鲜，是一种很好的工作方式，不过我认为有利有弊。

　　首先说缺点：

1. 不能称之为缺点，只是针对我们目前情况，觉得不是十分妥当，我觉得结队编程针对的应该是大牛级别，或者有一定编程能力的人。我们作为初学者，现在只能感受结对编程的魅力，却无法完美发挥它的优势。
2. 两个人对彼此的代码不十分熟悉，导致审核测试等过程效率降低。
3. 有时候思路不同，难分上下又难以统一。

　　然后说优点：

1. 合理分配成员任务，能使工作更高效。
2. 有助于成员间互相帮助，互相学习，提高代码水平。
3. 成员间互相审阅代码，有助于提高代码质量，减少bug发生。也能使成员间互相督促，相比较单独作战，更能让人认真起来。
4. 结对编程避免了“我的代码”还是“他的代码”的问题，使得代码的责任不属于某个人，而是属于两个人，进而属于整个团队，这样能够帮助建立集体拥有代码的意识，在一定程度上避免了个人英雄主义。 

　　对于本次Pair Project，我和partner配合比较成功，

　　我对partner的评价：昊岩是一个超级认真的大学霸，做事情一丝不苟，为了研究算法，特意跑到新主教去细致调查了一下实际电梯的运行方式！然后为了画好UML图一步一步调试，很辛苦的自习到很晚！超级棒的partner！而且很能抠细节，往往能注意到别人发现不了的问题，对于程序修改帮助十分大！

　　至于缺点，暂时还没想到~，不过他非让写，即使工程量大也不要这么学霸，给人压力好大。

　　partner对我的评价：刚接到分组说我和明源一组，我非常高兴。因为我和明源合作很长时间了，包括英语partner在内的多次双人或多人结队活动。明源给我的第一印象就是踏实，做事稳重踏实，让我非常放心。这次的结对工作中，我们分工明确，首先我们共同讨论工作的整体算法，然后他重点搞代码优化、我重点搞图形建模，然后互相审核，共同完成博客的编辑。自始至终的所有环节，明源都一丝不苟的完成，为我们的算法思想提出了很多建设性意见，使得我们的工作完成的非常理想。虽然我们的水平不如大牛们，但是我们的收获确实超出对自己的预期值，谢谢明源对我的支持与帮助。

      至于必须写的一个缺点嘛……明源你下次写代码时多写点注释，我改的时候也方便些哈。。

 

---

 

 　  Design by contract :

　　契约式设计（DbC），是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的“契约”或者说“契约”是一种比喻，因为它和商业契约的情况有点类似。

　　DbC的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。

　　DbC的关键：

　　一 前置条件（precondiction）：

　　为了调用函数，必须为真的条件，在其违反时，函数决不调用，传递好数据是调用者的责任。

　　二 后置条件 （postcondion）：

　　函数保证能做到的事情，函数完成时的状态，函数有这一事实表示它会结束，不会无休止的循环

　　三 类不变项（class invariant）：

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

　　

　　通过对http://www.cnblogs.com/riccc/archive/2007/11/28/design-by-contract-dbc.html博客的仔细阅读，发现他对于契约式设计有一个我觉得十分明白的比喻，现引用过来加以学习理解。

　　契约式设计就是要求提供一套机制，在客户程序与提供者之间明确的声明双方的职责与权利，即契约，并能够对这些契约进行验证。Building bug-free O-O software: An introduction to Design by Contract ™中的例子：向一个有限容量的字典（使用字符串键值存取各个元素）中插入某个元素，契约如下：

	义务	权利
客户程序	(必须保证前置条件)   确保字典没有满，键值是非空字符串	(从后置条件获益)   更新字典使新的元素出现在字典中，并跟给定的键关联起来
提供者	(必需保证后置条件)   将给定元素放入字典中，并跟给定的键关联起来	(可以假定前置条件成立)   如果字典满了，或者键值为空字符串，可以不处理

使用Eiffel语法描述：假如这是一个范型类DICTIONARY[ELEMENT]的put方法

put(x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable through key.
require
    count < capacity
    not key.empty
do
    ... Some insertion algorithm ...
ensure
    has (x)
    item (key) = x
    count = old count + 1
end

 这个例子中，很好的体现了客户和提供者之间的契约关系，前置条件和后置条件清晰易懂。

　　本次Pair Project 中，由于关系复杂，这种契约关系不是十分清晰易懂，不过还是处处可见,对Elevator、Passengers的操作，对EnterElevator,LeaveElevato,ReqStopAt等等方法的运用 ，更是集中体现了DbC的特点，用户与提供者错综复杂的关系在前置条件和后置条件的制约下工作得井井有条。

---

 information hiding , interface design and loose coupling:

　　information  hiding:在面向对象方法中，信息隐藏通过对象的封装性来实现。把希望隐藏的变量设置成private类型，对外公开接口，外界只有读权限。　　

　　interface design：界面设计，世界级图形设计大师 Paul Rand（保罗.兰德）曾经说过：“设计绝不是简单的排列组合与简单地再编辑，它应当充满着价值和意义，去说明道理，去删繁就简，去阐明演绎，去修饰美化，去赞美褒扬，使其有戏剧意味，让人们信服你所言……”，由此可见，设计绝非轻而易举之事，优秀的设计更是难上加难。界面设计师Joshua Porter 博客当中的一篇文章——《Principles of User Interface Design》，文章中列举了 20 大 UI 设计原则，现做简单总结：1.清晰度要高 2.要注重用户的体验和交互 3.区分重点 4.视觉层次感 5.内嵌帮助选项 6.界面的存在是有价值的 7.外观追随功能 8.直接操作的感觉是最好的。

　　loose coupling：松散耦合是指使用另一个组件提供服务的一个组件对前者的依赖性不强：它是语言独立的、平台独立的事务。

 

---