1 结对编程

　　1.1 结对编程的优缺点

优点：

与单独开发相比，结对能够使人们在压力之下保持更好的状态。结对编程鼓励双方保持代码的高质量，即使在出现了让人不得不飞快地编写代码的压力时仍然如此。

它能够改善代码质量。代码的可读性和可理解性都倾向于上升至团队中最优秀的程序员的水平

它能够缩短进度时间表。结对往往能够更快地编写代码，代码的错误也更少。这样一来，项目组在项目后期花费在修正缺陷的时间会更少。

缺点：

对于有不同习惯的编程人员，可以在一起工作会产生麻烦，甚至矛盾。

两个人在一起工作可能会出现工作精力不能集中的情况。程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。

可能让某些人有滥竽充数的机会

　　1.2 结对伙伴的优缺点

2 Information Hiding, interface design, loose coupling

　　2.1 Information Hiding

　　信息隐藏指在设计和确定模块时，使得一个模块内包含的特定信息（过程或数据），对于不需要这些信息的其他模块来说，是不可访问的。

　　信息隐藏是结构化设计与面向对象设计的基础。在结构化中函数的概念和面向对象的封装思想都来源于信息隐藏。软件业对这个原则的认同也是最近十年的事情。
      David Parnas在1972年最早提出信息隐藏的观点。他在其论文中指出：代码模块应该采用定义良好的接口来封装，这些模块的内部结构应该是程序员的私有财产，外部是不可见的。Fred Brooks在《人月神话》的20周年纪念版中承认了当时自己对Parnas的批评是错误的。他说道：“我确信信息隐藏--现在常常内建于面向对象的编程中--是唯一提高设计水平的途径”。
以下列举了一些信息隐藏原则的应用。
     1.  多层设计中的层与层之间加入接口层；
     2.  所有类与类之间都通过接口类访问； 
     3.  类的所有数据成员都是private，所有访问都是通过访问函数实现的；

　　2.2 interface design

　　每一个大的系统都是有许多模块系统组成的，系统的开发是一个很大的工程，开发起来得难度也是比较大。因此任何一个有一定规模系统，通常会把系统做一定分解降低分析设计开发的难度，模块划分是一个比较常见的方式，而模块与模块之间则是通过接口设计将它们整合在一起的。实践中，极有可能出现两种状况：接口维护失控或者过严而死板（而影响开发）。接口失控是因为接口的维护太过随意，因为A模块的需要就轻易在B模块中添加一个接口（方法），导致该接口（方法）非独立性（基本上只给模块A的这个功能点使用），或者是接口的控制过严，导致或者工作效率不高，或者接口的易用性不好。 原因在于：接口是两个模块间的耦合，而发生的种种问题在于模块耦合太过紧密；同时实践中，把模块对外提供的接口，与模块需要实现的外部模块的接口混为一谈。根据指导原则：为了降低耦合只有在中间加一层。一种可行的实践是：不轻易为模块设计对外提供的接口（方法），除非是通过重构得来的；模块对外提供两种类：一个是需要外部模块实现的接口（接口设计从本模块需要出发，当然每个接口尽管是为某个功能点服务，但也要注意其在模块内通用性），另一个是其它模块要求本模块实现的接口的实现类。即：A模块拥有一些需要B模块实现的接口（A模块对B模块的要求），而B模块中也有要求A模块实现的接口，因而A有这些接口的实现类。这种实践方式的好处在于：模块的接口就多了一层隔离降低了耦合，把接口的通用性和接口的适应性分离，又明确了模块的边界，使得接口在日后的优化和调整有了缓冲。接口设计的关键是能够将系统的每一个模块能够很好的整合在一起，而且能够让系统能够更好的运行。模块接口设计也是实现系统功能实现整体化的手段，而且是有益于系统拆分、整合等手段所必备的。

1.单一职责原则 - Single Responsibility Principle(SRP)  
就一个类而言，应该仅有一个引起它变化的原因。 职责即为“变化的原因”。  2.开放-封闭原则 - Open Close Principle(OCP)  
软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。对于扩展是开放的,对于更改是封闭的. 关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来。开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象. 拒绝不成熟的抽象和抽象本身一样重要 )  
3.里氏替换原则 - Liskov Substitution Principle(LSP)  子类型(subclass)必须能够替换掉它们的基类型(superclass)。  
4.依赖倒置原则(IoCP) 或 依赖注入原则 - Dependence Inversion Principle(DIP)  
抽象不应该依赖于细节。细节应该依赖于抽象。Hollywood原则: "Don‘t call us, we‘ll call you". 程序中所有的依赖关系都应该终止于抽象类和接口。针对接口而非实现编程。任何变量都不应该持有一个指向具体类的指针或引用。任何类都不应该从具体类派生。 任何方法都不应该覆写他的任何基类中的已经实现了的方法。 
5.接口隔离原则(ISP)  
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。多个面向特定用户的接口胜于一个通用接口。  包(类库、DLL)内聚原则  6.重用发布等价原则(REP)  重用的粒度就是发布的粒度。  7.共同封闭原则(CCP) 

　　2.3 loose coupling

　　在过去常用的程序架构中，多数应用程序之间直接相互通信。当应用程序需要修改或淘汰时，这种依赖便成为一个实际问题。任何修改都可能会按其自身的方式更新每条唯一的通信线路。因此，这种变更可能代价高昂。这种情况被称为应用程序间的紧耦合，也逐渐成为让一些企业头疼的问题。

　　另一方面，SOA（面向服务的体系结构） 将松耦合作为成功的企业级应用程序集成的一个主要原则。与紧耦合相反，松耦合是：

　　限制请求者应用程序代码和提供者应用程序代码的相互了解。如果耦合的服务任何方面有所变化，那么，请求者或提供者的应用程序代码（更可能是两者同时）必须改变。如果任何一方（请求者、提供者或中介基础架构）对解耦的服务任何方面作出改变，那么其它几方不必随之改变。

　　松耦合系统通常是基于消息的系统，此时客户端和远程服务并不知道对方是如何实现的。客户端和服务之间的通讯由消息的架构支配。只要消息符合协商的架构，则客户端或服务的实现就可以根据需要进行更改，而不必担心会破坏对方。松耦合通讯机制提供了紧耦合机制所没有的许多优点，并且它们有助于降低客户端和远程服务之间的依赖性。但是，紧耦合性通常可以提供性能好处，便于在客户端和服务之间进行更为紧密的集成（这在存在安全性和事务处理要求时，可能是必需的）。

　　对于松耦合，我虽然没有参与过比较大型规范的软件开发，但是在一些个人程序中也感受到了松耦合思想的重要性。

　　松耦合不仅对通讯机制有很大的益处，它作为一种思想在程序设计、结构方面都能有很大的启发。松耦合，其实是强调模块的独立性。

3 Design by Contract, Code Contract

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

DbC六大原则

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

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

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

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

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

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

 DbC对于软件工程是一个极大的理论改革，对于C/S模式造成了极大的影响和冲击。对于C/S模式，我们看待两个模块的地位是不平等的，我们往往要求server非常强大，可以处理一切可能的异常，而对client不闻不问，造成了client代码的低劣。
而在DbC中，使用者和被调用者地位平等，双方必须彼此履行义务，才可以行驶权利。调用者必须提供正确的参数，被调用者必须保证正确的结果和调用者要求的不变性。双方都有必须履行的义务，也有使用的权利，这样就保证了双方代码的质量，提高了软件工程的效率和质量。
缺点是对于程序语言有一定的要求，契约式编程需要一种机制来验证契约的成立与否。而断言显然是最好的选择，但是并不是所有的程序语言都有断言机制。那么强行使用语言进行模仿就势必造成代码的冗余和不可读性的提高。比如.NET4.0以前就没有assert的概念，在4.0后全面引入了契约式编程的概念，使得契约式编程的可用性大大提高了。此外，契约式编程并未被标准化，因此项目之间的定义和修改各不一样，给代码造成很大混乱，这正是很少在实际中看到契约式编程应用的原因。

在我们的编程中，函数间的调用基本运用了契约式编程的思想，要求传入的参数必须满足特定的要求。

4 Unit test

5 UML图

6 算法详解

PairWork-电梯调度程序结对编程