结队编程报告
小组成员：11061175 黄宇冰
11061170 罗洪运
关于我的队友：
虽然已经大三了吧，但是这的确是我与他的第一次接触，当我看到结队结果的时候我的第一反应是这个人是谁。听起来一定感觉我们这组完蛋了，但我很庆幸，我的这位队友很好相处也很给力。合作期间没有争执，我感觉还是很默契的><。从代码的阅读理解、到代码优化两个人都分工明确。
关于我们的分工：
代码理解：黄宇冰、罗洪运
代码初步编程：黄宇冰
算法描述：罗洪运
代码优化：罗洪运
代码测试：罗洪运
UML图：黄宇冰
整理汇总：黄宇冰、罗洪运
关于结队编程：
优点
我觉得结对编程之所以有效无非是基于一个常识，那就是两个人的共同盲点并不多。自己在代码上缺乏一定的整体性，而在这点罗洪运对于我是一个互补。除此之外，结对编程的效率绝对是非常高的，或者说你们队友在一边熬夜写代码，你一定就不好意思去看美剧了。两个人互相监督，互相掌握着进度是一种督促。两个人的交流十分重要
缺点
相反的，结对编程也有一个缺点，就是两个人的时间不能完全统一，我们只能制定一个大致的计划，然后按照计划去尽可能完成。
队友优缺点：
黄宇冰：
优点
时间观念强，有规划，踏实努力
不足：
罗洪运：
优点 做事认真，执着，能够坚持
不足
做事慢，时间观念不强
Information Hiding&& interface design&& loose coupling
信息隐藏：
它是指一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的（隐藏的），其实也就是强调了软件开发过程中的封装性。信息隐藏实际上还有一个很大的用处，我们在 软件中隐藏了一些因素，那么在将来由于这些因素变化而需修改软件时，只需修改这些个别的模块，其它模块不受影响。总的来说信息隐蔽技术不仅提高了软件的可维护性，而且也避免了错误的蔓延，改善了软件的可靠性。
接口设计
四大原则：
1。简单原则
2。封闭原则
3。完整性原则
4。可置换原则
松耦合
所谓“耦合”，指将两个元素像链子一样连接在一起。在软件领域，“耦合”一般指软件组件之间的依赖程度。松耦合系统通常是基于消息的系统，此时客户端和远程服务并不知道对方是如何实现的。客户端和服务之间的通讯由消息的架构支配。只要消息符合协商的架构，则客户端或服务的实现就可以根据需要进行更改，而不必担心会破坏对方。松耦合通讯机制提供了紧耦合机制所没有的许多优点，并且它们有助于降低客户端和远程服务之间的依赖性。但是，紧耦合性通常可以提供性能好处，便于在客户端和服务之间进行更为紧密的集成（这在存在安全性和事务处理要求时，可能是必需的）。
关于代码的理解：
Scheduler 功能：接受并且缓存请求，分配给每个电梯的Task。Task 功能：收到Scheduler指定的任务，指挥电梯运动。
Task 逻辑详解：Task 可以理解为电梯的当前任务，其有三个重要成员变量，State（任务状态），TaskDirection（任务方向），TaskFloor（任务楼层）。
State有三个状态
Idle（空闲）：即电梯当前没有任何任务，停止在某一楼层状态。
Pick（接人）：即电梯在空闲时，收到一个Scheduler指定来的Direction请求，即有乘客要求上电梯时，电梯驶向乘客方向去接人的状态。
Drop（下人）：即电梯在任何时候收到一个Scheduler指定来的Destination请求后，电梯按着TaskDirection方向行驶，并且在需要停靠的楼层开门使人上下的状态。
电梯初始状态一般是 Idle，会顺序地从 Idle -- 收到请求 --> Pick --到达呼叫楼层--> Drop --按着TaskDirection方向走到最后一站--> Idle 经历这些状态。
Scheduler 循环逻辑过程：
收到请求：按照请求类型（Destination or Direction）缓存。 循环过程：首要分配Destination类型请求，次要分配Direction类型请求，之后更新电梯的超重状态。
分配Destination请求： 记 该请求的电梯的Task 为 tsk。 如果该tsk的TaskDirection方向与前往 destination 的方向相同，则成功分配；否则不成功 分配成功，则移除该请求；否则，保留在请求列表。
分配Direction请求： 遍历所有电梯，优先寻找一台“顺路”电梯，“顺路”满足下面条件中任一 1、状态为Idle && 未超重 && 正好停在该楼层 2、状态为Pick && 未超重 && 任务方向和请求方向一样 && 路过该楼层或者正在行驶的方向和任务方向相反 3、状态为Drop && 未超重 && 任务方向和请求方向一样 && 路过该楼层 如果找到则马上返回分配成功，否则次要搜索一台停在任意楼层的空闲电梯。 分配成功，则移除该请求；否则，保留在请求列表。
我们的算法：
因为考虑到0、1层请求较多，而且从0、1层能够最大的将请求覆盖，所以每次尽量让电梯接往下的请求。
1、如果电梯正在运行，对外部请求进行考虑，如果外部请求所在楼层在外部电梯和当前目标楼层之间且方向相同，同时为避免乘客上了电梯由于超重又下电梯的情况，对超重进行预测，如果电梯剩余负载小于乘客平均体重，则接收此请求，更新目的楼层；否则不接收外部请求。
2、如果电梯当前状态为静止，则只用考虑外部请求，根据电梯的当前位置，将请求分为4中，下下、下上、上上、上下（前一个“上”、“下”表示请求楼层相对于电梯位置，后一个“下”、“上”表示请求要去的方向），并统计四个方向人数。按下下 、 下上、上上、上下优先级从高到低相应请求，但同时各个楼层、方向请求的数量也影响最终的调度：
如果下下人数大于下下人数，才将电梯目的楼层定位下下请求中离电梯最近的请求；
如果下上人数大于上下人数，才将电梯目的楼层定位到下上楼层
否则按照下下、下上、上上、上下的顺序响应。
（测试中下上和上下请求数的比较后不一定比不进行比较快，但是我认为在数据足够多的情况下，平均时间是有降低的，而且除了上述四个情况，如果考虑所有往下的请求和所以往上的请求，在之前算法的基础上再并进行相应的控制，是可以找到一个相对很优的调度算法）
关于类图：
队友博客地址：http://www.cnblogs.com/icehorn924/p/icehorn.html