优势：

　　1 ）降低程序各个部分之间的耦合性，使程序模块互换成为可能。调用的客户端无需知道具体使用的对象类型，只要对象有客户希望的接口可以使用，对象具体是如何实现这些接口的，客户并不需要考虑。

　　2 ）简化了程序各个部分的单元测试，将需要测试的程序模块中通过重构提炼出抽象的接口，然后编制和接口一致的 Mock 类，测试会变得很容易。如果应用了测试优先的方法，从简化客户端调用的角度，还可以经过抽象改善软件模块的设计。

　　3 ）模块的部署升级由于模块之间的耦合度降低变得更加容易。

　　相关的设计模式有创建型模式中的工厂模式，结构型模式中的代理模式和组合模式等。

　　2．  对象组合优于类继承。

　　面向对象为软件开发引入了三大工具：继承，多态和重载。继承使得程序员可以快速的通过扩展子类来增加功能，但是由于 继承是在编译时确定的，因此增加的功能较多时，继承不够灵活，还有可能出现“子类爆炸”的局面（为了完成新添功能，不得不在继承体系中添入大量的之间只有 细微差别的子类，掌握使用扩展都会变得非常困难）。而通过对象的组合，可以动态透明的添加功能。相关设计模式有装饰模式和代理模式等。

　　3．  分离变化。

　　前面说过需求是在不断变化的，不同的变化可能是仓库安全库存的计算方法，可能是报表和数据的展现形式，通过把这些不同的变化识别并分离出来不同的对象委托，简化了客户端的调用和升级。相关的设计模式有命令模式，观察者模式，策略模式，状态模式，模版方法模式等。

　　二、具体原则：

　　1．  单一职责原则 srp （ single responsibility principle ）

　　一个模块的功能应该尽可能的内聚。如果一个类发生了变化，引起变化的原因应该有且只有一个。每一个类承担的职责都是 一个变化的轴线，需求变化时，会体现为类的职责的变化。如果一个类承担的职责过多，等于把这些职责耦合在了一起，一个职责的变化会影响这个类完成其他职 责的能力，会出现前面所说的软件的臭味之一脆弱性。相关的设计模式有

　　2．  开放封闭原则 ocp （ open closed principle ）

　　一个模块应该对功能的扩展开放，支持新的行为，对自身的更改封闭。每次对模块的修改都可能会引入新的错误和新的依赖。因此扩展新功能时，已经编好的模块源码和二进制代码都是不应该修改的。相关的设计模式有适配器模式，桥接模式，访问者模式等。

　　3．  Liskov 替换原则 lsp （ liskov subtitle principle ）

　　子类型必须可以替换掉他的基类型。一个基类的多个子类型之间要完成动态的替换，各个子类型必须都可以被他们的基类型 替换，这样他们之间动态替换后，客户端调用的代码不需要冗赘的 switch 类型判断代码。如果 子类型无法替换基类型，将会导致在派生类对象作为基类对象进行传值时的错误。这样多态机制处于瘫痪状态了。相关设计模式为组合模式。

　　4．  依赖倒置原则 dip （ dependent inverse principle ）

　　高层模块不应该依赖于底层模块，抽象不应该依赖于细节，细节应该依赖于抽象。假定所有的具体类都是回变化的，因此如 果一个客户端依赖于（调用或声明）具体的类型，那么当这个具体的类型变化时，依赖的客户端业必须同时进行修改。这些具体的更改可能出现在使用了某个特定的 网络协议，特殊的系统 api 调用，特定的数据库储存过程等，这些用法或多或少都会使客户端调用和具体类型成为铁板一块，比较难于重用。 Java 社区中比较热门的 j2ee 轻量级容器框架 spring 很好的实现了本原则。

　　5 ．接口隔离原则 isp （ interface segregation principle ）

　　不应该强迫客户依赖于它们不使用的方法。因为每一个实现接口的对象必须实现所有接口中定义的方法。如果接口的粒度比较小，实现接口的对象可以使用一种即用即付的方式动态实现接口。每个接口的粒度很小，复用起来也非常容易。

　　这体现了一个趋势：为了更好的实现重用，接口，函数，模块和类等倾向于更容易使用的“小”体积。

　　敏捷软件开发的宣言和实践：
 
　　软件开发项目的失败使得人们开始思考软件开发的过程，人们希望通过引入严格的过程控制产生软件生命周期中各个阶段的文档和制品来保证软件的质量。比较出名的业界实施方法论有 cmmi （能力成熟度模型）和 rup （瑞理统一过程），这些方法论都是重型的。　　

　　举例来说，没有经过剪裁的 Rup 实现起来，至少需要在全周期完成四十个以上的制品文档，文档的编写维护和源代码的同步等需要非常多的资源，十人以下的开发团队一般没有精力、时间、人员配 置完成这些制品。失控的过程的膨胀迫使人们寻找一种快速工作，相应变化的“敏捷的”方法。敏捷团队提倡通过团队成员之间充分有效的沟通统一大家的目标，结 伴的方式完成开发技术的团队内传承，使用“够用好”的轻量甚至免费的工具管理过程。可以正常工作的代码摆在首要地位，只有必要的时候才生产必要的文档。 强调和客户面对面地交流合作，积极地响应客户需求的变化而不是遵循机械的计划。

　　使用较短的迭代周期，近早和持续提交有价值的软件给客户来验证并修正和用户需求的吻合程度。提倡可以持续的稳定的开发节奏，长期“小步快走”的方式代替突然的“百米冲刺”。保持设计优，简单的设计并且持续改进，不断调整。