结对项目小记
——by 12061227 康 12061179 宇帆
结对编程就是一种敏捷软件开发的方法，两个人在一个计算机上共同工作。一个人输入，而另一个人检查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。
在结对编程中，观察员同时考虑工作的战略性方向，提出改进的意见，或将来可能出现的问题以便处理。这样使得驾驶者可以集中全部注意力在完成当前任务的"战术"方面。观察员当作安全网和指南。结对编程对开发程序有很多好处。比如增加纪律性，写出更好的代码等。
结对编程的优点在于每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。具体地说，结对编程有如下的好处：
两个人的激烈讨论产生了很多灵感，在我们在讨论中，常常会想到非常好的点子来解决在编程过程中不断出现的新问题。 
对我们自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
在心理上, 当有另一个人在你身边和你紧密配合, 做同样一件事情的时候, 你不好意思开小差, 也不好意思糊弄。
增强代码和产品质量，并有效的减少BUG。
总之，如果运用得当，结对编程能得到更高的投入产出比（Return of Investment）。
结对编程的缺点我认为在于
完成同一个功能的代码可能不同人实现的方式是不一样的，假设他们写出来的都是很优质的代码。这个时候就需要结对双方都能够意识到并承认这一点。结对的本质是用两个人的大脑拼接出最优质的代码，如果代码已经是最优了，那就无需对这段代码妄加评论了。这样就产生了反效益的产出
有时候，程序员们会对一个问题各执己见，争吵不休，影响工作效率
有些程序员不喜欢在工作的时候身后/或旁边 有人盯着，有一种被监视的感觉。
有的人认为编码要进行独立思考，而独立思考过程是一个私人的问题，有问题可以在专门的会议上讨论，但当你在分析处理具体问题时候总有人在旁边啰里八嗦的时候不会感到愉快。
有经验的人更喜欢单刀直入，找个人来站在他背后看着他可能会让他感到非常的不适，最终导致编程时受到情绪影响，反而出现反作用。
安康同学的优点在于：1.工作非常认真 2.工作过程中积极向上，充满热情。3.工作效率奇高，有很多非常好的点子。
刘宇帆同学的优点在于：1.工作态度良好，所以很少发生争执。 2.对工作方向态度乐观 3.具有较好的分析能力
刘宇帆同学的缺点在于：个人技术能力不够强
Information Hiding, interface design, loose coupling 的应用
Information Hiding即数据隐藏，在面向对象的程序设计过程中，使得一个模块内包含信息(过程或数据)，对于不需要这些信息的其他模块来说，是不能访问的。在面向对象方法中，信息隐蔽是通过对象的封装性来实现的。实现方法可以是类的成员变量的可见性统一成private，并设计相应的属性。
interface design即接口设计，它的优点在于使程序具有良好的封装性，便于扩展功能而不影响原来的类是封装的一个主要的好处，就是增加软件代码的内聚性。通过增加内聚性，进而提高可复用性和可扩展性。接口能够提供给后面的程序设计一个宏观的控制，我们通过接口能很快的知道电梯、乘客的调度方案、请求都有哪些属性，要实现哪些方法，而不用关心具体的实现细节。
loose coupling即松耦合，软件功能模块的设计和划分按照OO（面向对象）的思想，遵循"强内聚，弱耦合"的原则，也就是尽量将相互依赖的类放在一个命名空间（包）中，内部结构和联系要尽量紧密——强内聚；对外模块尽量与其他方法或功能减少 耦合---弱耦合 ，以便功能上或代码上可以达到重用，再组合新功能的时候，可以像搭积木一样，分别拿出去再重用，而不会太关联其他。
Pair Work中的Design by Contract, Code Contract
在Design by Contract（契约式设计）的模式中，这是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的"契约"或者说"契约"是一种比喻，因为它和商业契约的情况有点类似。
在这种模式下，优点是使用者和被调用者地位平等，双方必须彼此履行义务，才可以行驶权利。契约所核查的，是"为保证正确性所必须满足的条件"，因此，当契约被破坏时，只表明一件事：软件系统中有bug。双方都有必须履行的义务，也有使用的权利，这样就保证了双方代码的质量，提高了软件工程的效率和质量。
在Design by Contract（契约式设计）的模式中缺点也是不可避免的，由于契约的限制比较大，在有的模式存在有改动的时候变更的部分会更多，而且契约式编程需要一种机制来验证契约的成立与否。而断言显然是最好的选择，但是并不是所有的程序语言都有断言机制。那么强行使用语言进行模仿就势必造成代码的冗余和可读性的降低。
UML类图
