敏捷软件开发6大原则

Agile development采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

1.单一职责原则（Single Responsibility Principle - SRP）

There should never be more than one reason for a class to change。
永远不应该有多于一个原因来改变某个类。
对于一个类而言，应该仅有一个引起它变化的原因。不同的类具备不同的职责，各施其责。

2.开放封闭原则（Open Closed Principle - OCP）

Software entities like classes, modules and functions should be open for extension but closed for modifications。
软件实体，如：类、模块和函数，对于扩展应该是开放的，但对于修改应该是封闭的。
当需求有改动时，应该通过继承或组成的方式来扩展类的功能，而不是直接修改类的代码。

3.里式替换原则（Liskov Substitution Principle - LSP）

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it。
使用基类的指针或引用的函数，必须是在不知情的情况下，能够使用派生类的对象。
在继承类时，务必重写父类中所有的方法，子类尽量不要暴露自己的public方法供外界调用。在设计接口或抽象类时，子类必须完全实现父类的抽象方法，子类可以增加自己特有的方法，但是尽量不要重写父类的方法，LSP说明父类能够替换子类，但是子类不一定能够替换父类。

4.最少知识原则（Least Knowledge Principle - LKP）

Only talk to you immediate friends。
只与你最直接的朋友交流。
减少对象之间的交互，不要让一个类依赖于太多其他类，即减少类之间的耦合，低耦合，高内聚。

5.接口隔离原则（Interface Segregation Principle - ISP）

The dependency of one class to another one should depend on the smallest possible interface.。
一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。
设计应用程序时，若一个模块包含多个子模块，那么应该对模块做出抽象。设想该模块由一个类实现，我们可以把系统抽象成一个接口。但是要添加一个新的模块扩展程序时，如果要添加的模块只包含原系统中的一些子模块，那么系统就会强迫我们实现接口中的所有方法，并且清寒要编写一些哑方法。这样的接口被称为肚胖接口或者被污染的接口，使用这样的接口将会给系统引入一些不当的行为，这些不当的行为可能导致不正确的结果，也可能导入资源浪费。ISP说明：一，一个类对另外一个类的依赖性应该是建立在最小的接口上的；二，客户端程序不应该依赖它不需要的接口方法/功能。

6.依赖倒置原则（Dependence Inversion Principle - DIP）

High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.。
高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置。