标签：des blog http io os ar 使用 for strong
结对人员：马佐霖 王迪
1.结对编程
1.1结对编程优缺点
（1）首先应该是结对编程的高效率了，结对编程的时候，两个人可以分开做不同的unit，也可以同时做相同的unit。在项目的一些简单的unit，一个人能够很简单的unit就可以分给不同的人去做；对于核心的unit，比如说此次项目电梯调度的算法部分，这是一个核心的部分，需要我们共同讨论，经过讨论后再去实现，或者两个人分别写出自己的想法，用代码实现，这时候，综合两个人效率高的那个人的算法。另外，在结对编程时候，有一定相互监督作用，比起一个写程序，更不会想去玩一些其它的东西。
（2）想法源于两个人的激烈讨论，很多时候，我们在讨论中，常常忽然就会有一个灵感突然来袭，或者是会有一些之前不懂得地方，可能一下就懂了。
（3）结对编程的时候乐子多，我们合作的很开心，这样能提高我们的激情，同时也就提高了效率，工作起来很带劲
（4）在调试的时候，不再是一个人调试时那样无奈了，遇到了bug时，两个人一起，上面那张相片就是我们两个人在调试时候留下的，这时候，有两个人的经验，应付这些bug就能更得心应手一些了。后期维护起来也更加方便。
1.2结对伙伴优缺点
我的优点：（1）认真；（2）热情；（3）比较幽默，能跟伙伴一起很好地工作
我的缺点：容易钻牛角尖，项目进度有些慢
马佐霖的优点：（1）乐观；（2）编码速度比较快；（3）交流能力好
马佐霖的缺点：经验比较不足
2.Information Hiding, interface design, loose coupling
2.1Information Hiding
信息隐藏指在设计和确定模块时，使得一个模块内包含的特定信息（过程或数据），对于不需要这些信息的其他模块来说，是不可访问的。
信息隐藏是结构化设计与面向对象设计的基础。在结构化中函数的概念和面向对象的封装思想都来源于信息隐藏。软件业对这个原则的认同也是最近十年的事情。
David Parnas在1972年最早提出信息隐藏的观点。他在其论文中指出：代码模块应该采用定义良好的接口来封装，这些模块的内部结构应该是程序员的私有财产，外部是不可见的。Fred Brooks在《人月神话》的20周年纪念版中承认了当时自己对Parnas的批评是错误的。他说道：“我确信信息隐藏--现在常常内建于面向对象的编程中--是唯一提高设计水平的途径”。
以下列举了一些信息隐藏原则的应用。
1. 多层设计中的层与层之间加入接口层；
2. 所有类与类之间都通过接口类访问；
3. 类的所有数据成员都是private，所有访问都是通过访问函数实现的；
2.2interface 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.3loose coupling
在过去常用的程序架构中，多数应用程序之间直接相互通信。当应用程序需要修改或淘汰时，这种依赖便成为一个实际问题。任何修改都可能会按其自身的方式更新每条唯一的通信线路。因此，这种变更可能代价高昂。这种情况被称为应用程序间的紧耦合，也逐渐成为让一些企业头疼的问题。
另一方面，SOA（面向服务的体系结构） 将松耦合作为成功的企业级应用程序集成的一个主要原则。与紧耦合相反，松耦合是：
限制请求者应用程序代码和提供者应用程序代码的相互了解。如果耦合的服务任何方面有所变化，那么，请求者或提供者的应用程序代码（更可能是两者同时）必须改变。如果任何一方（请求者、提供者或中介基础架构）对解耦的服务任何方面作出改变，那么其它几方不必随之改变。
松耦合系统通常是基于消息的系统，此时客户端和远程服务并不知道对方是如何实现的。客户端和服务之间的通讯由消息的架构支配。只要消息符合协商的架构，则客户端或服务的实现就可以根据需要进行更改，而不必担心会破坏对方。松耦合通讯机制提供了紧耦合机制所没有的许多优点，并且它们有助于降低客户端和远程服务之间的依赖性。但是，紧耦合性通常可以提供性能好处，便于在客户端和服务之间进行更为紧密的集成（这在存在安全性和事务处理要求时，可能是必需的）。
对于松耦合，我虽然没有参与过比较大型规范的软件开发，但是在一些个人程序中也感受到了松耦合思想的重要性。
松耦合不仅对通讯机制有很大的益处，它作为一种思想在程序设计、结构方面都能有很大的启发。松耦合，其实是强调模块的独立性。
3.Design by Contract, Code Contract
4.unit test
5.UML图
6.算法
标签：des blog http io os ar 使用 for strong
原文地址：http://www.cnblogs.com/buaawd/p/4032744.html
